Le premier test est juste destiné à apprendre le fonctionnement basique des outils liés à BTRFS il a été executé sur des volumes LVM créés pour l'occasion avant de passer au travail sur des partitions physiques. 
Mais, ATTENTION, la version des outils n'est (sur Debian unstable) encore que "0.19+20120328-1". Cela bouge mais la version "stable" 1.0 est peut-être encore assez loin. 
Pour tester BTRFS il faut un noyau dont le support BTRFS est activé ! Si, comme c'est probable le support BTRFS est compilé en module un simple : 
modprobe btrfs 
devrait vous renseigner : 
FATAL: Module btrfs.ko not found. 
ou bien meilleur aucun message et un code retour 0. 
Ce support devrait être actif pour les noyaux récents de la plupart des distributions, sinon compilez le vous même et installez le. Les tests sont réalisés avec un noyau très récent (3.4.4) afin de bénéficier des dernières corrections. 
Ensuite il faut charger les outils BTRFS pour disposer, entre autres, de mkfs.btrfs. Sur Debian le paquet se nomme "btrfs-tools" sans autre complication et s'installe rapidement. 
Pour ce premier test j'ai créé deux "disques" LVM de 20G nommés : 
VOL_EXT4 et VOL_BTRFS. Le premier sera formaté classiquement en EXT4, le secon en BTRFS. 
La commande "mkfs.btrfs" assure le formatage et la labellisation, ici : 
date ; mkfs -t btrfs -L DISK_BTRFS /dev/mapper/TALE-VOL_BTRFS ; date 
vendredi 4 mai 2012, 19:55:30 (UTC+0200) 

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 
WARNING! - see http://btrfs.wiki.kernel.org before using 

fs created label DISK_BTRFS on /dev/mapper/TALE-VOL_BTRFS 
    nodesize 4096 leafsize 4096 sectorsize 4096 size 20.00GB 
Btrfs Btrfs v0.19 
vendredi 4 mai 2012, 19:55:30 (UTC+0200) 

Le résultat est quasi instantané ! 

En EXT4 : 
date; mkfs -t ext4 /dev/mapper/TALE-VOL_EXT4 ; date 
vendredi 4 mai 2012, 19:56:52 (UTC+0200) 
mke2fs 1.42.2 (9-Apr-2012) 
Filesystem label= 
OS type: Linux 
Block size=4096 (log=2) 
Fragment size=4096 (log=2) 
Stride=0 blocks, Stripe width=0 blocks 
1310720 inodes, 5242880 blocks 
262144 blocks (5.00%) reserved for the super user 
First data block=0 
Maximum filesystem blocks=4294967296 
160 block groups 
32768 blocks per group, 32768 fragments per group 
8192 inodes per group 
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000 
Allocating group tables: done                             
Writing inode tables: done                             
Creating journal (32768 blocks): done 
Writing superblocks and filesystem accounting information: done    
vendredi 4 mai 2012, 19:56:54 (UTC+0200) 

Deux secondes pour 20G, donc plus de trois minutes pour un disque de 2To. On monte ensuite les deux partitions et on vérifie : 
df | grep mnt 
/dev/mapper/TALE-VOL_EXT4    20907056    440692  19417788   3% /mnt/VOL_EXT4 
/dev/mapper/TALE-VOL_BTRFS   20971520       120  18845632   1% /mnt/VOL_BTRFS 
Tiens ETX4 consomme 3% ?

Tests "dd" en écriture, fichier de 8Go :  
Pour EXT4 wait 37 .. 75%    BO # 65000 .. 136000 (chiffres de "vmstat")  
256000+0 records in 
256000+0 records out 
8388608000 bytes (8,4 GB) copied, 63,0721 s, 133 MB/s

Pour BTRFS wait 29.. 55%          BO # 68000 .. 180000  
256000+0 records in 
256000+0 records out 
8388608000 bytes (8,4 GB) copied, 60,2699 s, 139 MB/s

Tests "dd" en écriture, fichier de 16Go : 

Pour EXT4 wait 37 .. 75% output # 65000 .. 136000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 136,869 s, 123 MB/s 

Pour BTRFS wait 29.. 55% output # 68000 .. 190000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 123,338 s, 136 MB/s 

La vitesse du BTRFS n'est que très peu supérieure mais les "wait_states" sont inférieurs (mesuré avec vmstat) mais reste plus constante pour les fichiers de 8G et 16G. 

Tests "dd" en lecture, fichier de 16Go : 

EXT4 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 125,661 s, 134 MB/s 

BTRFS : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 119,848 s, 140 MB/s 

Léger avantage à BTRFS.

Aucune commande complexe n'a été utilisée ici, la seule différence est la pose du label de FS par "mkfs.btrf" qui simplifie un peu les commandes. 
Les tests précédents ont étés réalisés avec un noyau "xenifié", ci-dessous le même test sur la même version de noyau (3.3.4) en mode "normal" : 
Test "dd" en lecture fichier 16Go :

EXT4 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 108,485 s, 155 MB/s 
BTRFS : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 99,3723 s, 169 MB/s 

Les résultats sont meilleurs laissant toujours un léger avantage à BTRFS. 
J'ai prévu de présenter plus loin quelques possibilités attrayantes et les outils qui permettent d'y arriver. C'est tout pour aujourd'hui ... à la prochaine.

Après plusieurs mois d'usage BTRFS se comporte très bien. 
J'ai eu un plantage (corruption) tout à fait au début mais les outils de réparation du FS ont fonctionné correctement bien que m'ayant rappelé avant lancement qu'ils n'etaient que des versions "beta" encore incomplètes.

Depuis je suis passé à des versions de noyau très récentes (3.5 et 3.6 maintenant) et je n'ai plus souffert d'un seul ennui. Je pense que le support BTRFS a été amené à maturité dans les dernières versions de noyau et qu'il est parfaitement envisageable de l'utiliser. J'ai d'ailleurs transféré tous mes répertoires personnels sur une partition RAID (/dev/mdx) formatée en BTRFS.

Au vu des sauvegardes que j'effectue régulièrement je n'ai pas vraiment testé les "snapshots" de BTRFS. 
Note 2016 : pas d'ennuis avec les noyaux de la série 4.x.
Note 2024 : BTRFS est toujours là et fonctionne normalement avec un noyau 6.7.

Ce dernier test doit permettre de mesurer toute la puissance et la souplesse de BTRFS car il va ici jouer deux rôles : 
- gestion du RAID 
- gestion du File system 
permettant ainsi de n'utiliser qu'un outil au lieu des deux habituels (Device Mapper ou LVM pour le RAID, Gestionnaire de FS tel EXT3, EXT4 ...). Pour améliorer la fiabilité (et la rapidité ?) les deux disques sont sur deux contrôleurs différents. On utilisera le parametre "odirect" de "dd" pour limiter l'influence de la mémoire. 
D'abord "casser" le RAID actuel, c'est super simple ... 

mdadm -S /dev/md0            # stopper le device 
mdadm --zero-superblock /dev/sde1    # effacer les traces 
mdadm --zero-superblock /dev/sdd1    # sur les deux disques 

Après cette petite opération il est de bon ton de redémarrer le système pour assurer une bonne reconnaissance des changements. effectués.
Sitôt dit, sitôt fait et on enchaîne sur la création de notre RAID1 BTRFS : 
mkfs.btrfs -m raid1 -d raid1 -L BTRFS /dev/sdc1 /dev/sdd1 
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 
WARNING! - see http://btrfs.wiki.kernel.org before using 
adding device /dev/sdd1 id 2 
fs created label BTRFS on /dev/sdc1 
    nodesize 4096 leafsize 4096 sectorsize 4096 size 800.00GB 
Btrfs Btrfs v0.19 
On monte ce nouveau FS : 
mount LABEL=BTRFS /mnt/DISK1omount LABEL=BTRFS /mnt/DISK1 
et on vérifie : 
df -k | grep mnt 
/dev/sdc1                   838860800      312 803151616   1% /mnt/DISK1 

Seul le premier disque est visible et le FS est bien noté 800GB. 
Un petit test "dd" en écriture : 
dd if=/dev/zero of=/mnt/DISK1/test bs=32K count=1536000 conv=fsync oflag=direct 
1536000+0 records in 
1536000+0 records out 
50331648000 bytes (50 GB) copied, 1001,96 s, 50,2 MB/s 

Pendant ce temps les deux disques sont actifs, chacun sur leur contrôleur : 
21:06:33 sdd   1577,00      0,00 100928,00     64,00      0,44      0,28      0,28     43,60 
21:06:33 sde   1578,00      0,00 100992,00     64,00      0,75      0,48      0,47     74,80 
Average: sdd   1577,00      0,00 100928,00     64,00      0,44      0,28      0,28     43,60 
Average: sde   1578,00      0,00 100992,00     64,00      0,75      0,48      0,47     74,80 

Pour corser un peu la comparaison je vais profiter de la partition "2" toujours en RAID-1 (Device Manager) pour la formater en BTRFS et comparer ainsi le RAID-1 BTRFS "pur" et le RAID-1 "DM" + BTRFS. La partition 2 étant un peu moins rapide du fait de sa position DM + BTRFS part avec un petit handicap (#5%). 
Les résultats bruts : 
RAID-1 BTRFS : 
1536000+0 records in 
1536000+0 records out 
50331648000 bytes (50 GB) copied, 966,6 s, 52,1 MB/s 
DM + BTRFS : 
1536000+0 records in 
1536000+0 records out 
50331648000 bytes (50 GB) copied, 993,912 s, 50,6 MB/s 
Au vu des chiffres on peut considérer qu'il y a égalité. 
Passons à la lecture et afin de vérifier si les deux disques sont bien utilisés on va tester deux configurations : 
DD avec l'option "idirect" 
DD sans l'option "idirect" 
RAID-1 BTRFS avec "idirect" : 
dd if=/mnt/DISK1/test of=/dev/null bs=32K conv=fsync iflag=direct 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 489,408 s, 103 MB/s 

Sans "idirect" : 
dd if=/mnt/DISK1/test of=/dev/null bs=32K conv=fsync 
dd: fsync a échoué pour « /dev/null »: Argument invalide 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 430,43 s, 117 MB/s 

DM + BTRFS avec "idirect" : 
dd if=/mnt/DISK2/test of=/dev/null bs=32K conv=fsync iflag=direct 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 508,961 s, 98,9 MB/s 

Sans idirect : 
dd if=/mnt/DISK2/test of=/dev/null bs=32K conv=fsync 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 380,004 s, 132 MB/s 

Avec l'utilisation de "idirect" les deux possibilités sont à peu près à égalité. Par contre sans ce flag le couple "DM" + BTRFS est très loin devant ... 
On refait le test en notant l'activité des différents disques sur une vingtaine de secondes : 
RAID1 BTRFS 
sar -pd 2 10 | egrep 'sdd|sde' | grep 'Average' 
Average: sde    309,50 213753,60      0,00    690,64      9,64     31,16      3,12     96,68 
Average: sdd      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 

DM + BTRFS 
Average: sde    187,60 140957,60      0,00    751,37      5,77     30,60      3,80     71,28 
Average: sdd    163,10 109883,20      0,00    673,72      4,26     26,19      3,96     64,56 

On remarque tout de suite que BTRFS n'utilise qu'un disque au cours de ce test alors que DM en utilise deux ce qui explique probablement la meilleure vitesse obtenue. 
Remarque : lors d'un deuxième test BTRFS a utilisé l'autre disque il est donc probable que sur plusieurs IO simultanées il est capable de se servir des deux disques. 
On vérifie avec deux "dd" en parallèle : 
Average: sde    937,40 207295,20      0,00    221,14     28,18     29,98      1,06     99,60 
Average: sdd      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 
Et bien non il se sert d'un seul disque ? Et avec deux fichiers différents que va-t-il se passer ? 
On copie d'abord une partie de notre fichier de 50G : 
RAID1 BTRFS 
dd if=test_UN of=test_DX bs=32K count=512000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 376,779 s, 44,5 MB/s 
Pendant la copie un seul disque est utilisé en lecture et bien sûr les deux en écriture. 
La vitesse est sensiblement moindre que lors des tests d'écriture seule 44,5 contre 52,1. 

DM + BTRFS 
dd if=test_UN of=test_DX bs=32K count=512000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 339,194 s, 49,5 MB/s 
Presque la vitesse en écriture seule 49,5 contre 50,6 ! Pendant la copie les deux disques sont utilisés en lecture et en écriture. 
Le test avec deux fichiers 
RAID1 BTRFS : 
Un seul des deux disques est utilisé et le contrôleur est à 100%, le temps de WAIT est élevé (30 à 45%) le CPU utilisé est de l'ordre de 10%  : 
Average: sde    202,70 204479,60      0,00   1008,78     23,49    116,10      4,93    100,00 
Average: sdd      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 
Fichier 1 ; 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 319,734 s, 52,5 MB/s 
Fichier 2 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 260,957 s, 64,3 MB/s 
Soit un total d'environ 117Mo/seconde parfaitement égal au test précédent. 
DM BTFRS 
Les deux disques sont utilisés et les deux contrôleurs à 100%, le temps de WAIT est très élevé (40 à 60%), le cpu utilisé varie de 14 à 28% : 
Average: sde    227,85 218987,20      0,00    961,10     13,08     57,72      4,39    100,00 
Average: sdd    210,60 215552,00      0,00   1023,51     11,94     56,74      4,74     99,92 
Fichier 1 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 99,329 s, 169 MB/s 
Fichier 2 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 155,029 s, 108 MB/s 

Soit un maximum de plus de 270 Mo/seconde ! J'ai refait le test en notant les vitesses moyennes de chaque disque (je rappelle que si les disques sont identiques ce n'est pas le cas des contrôleurs) : 
Average: sde    214,20 219289,60      0,00   1023,76     11,50     53,70      4,66     99,78 
Average: sdd    191,00 165808,40      0,00    868,11      9,27     48,44      5,02     95,92 
Un des disques va nettement plus vite ! Lors de ce second essai j'ai obtenu 150 et 112Mo/seconde soit environ 260Mo/seconde, ce qui est en phase avec le premier essai. 

En bref DM + BTRFS ça a l'air de déménager. Ce petit problème réglé je vais remettre la partition 1 en mode "DM". 
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1 
On reboote par précaution ... et on lance 
mkfs -t btrfs -L BTRFS_1 /dev/md0 
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 
WARNING! - see http://btrfs.wiki.kernel.org before using 

fs created label BTRFS_1 on /dev/md0 
    nodesize 4096 leafsize 4096 sectorsize 4096 size 399.87GB 
Btrfs Btrfs v0.19 
Et la synchronisation du raid commence : 
md0 : active raid1 sdd1[0] sde1[1] 
      419299136 blocks super 1.2 [2/2] [UU] 
      [>....................]  resync =  0.1% (515264/419299136) finish=67.7min speed=103052K/sec 
Ces nouveaux disques de 2To semblent nettement plus rapides que les "anciens" disques de 750 Go (2 and déjà) déja présents dans la machine. 
Ne pas oublier ensuite de positionner ce nouveau "raid" dans le fichier "/etc/..../mdadm.conf", 
mdadm --examine --scan 
est votre ami. 
Il est toutefois à noter que j'ai eu quelques plantages système, crash complets sans possibilité de reprendre la main ou "ooops" déclenchant une violation de protection mémoire de "dd" et un crash lors de l'utilisation de "cp -dpR" pour recopier une arborescence complète.

Ces plantages ont eu lieu avec des noyaux < 3.3. Avec un noyau 3.3.5 les plantages ont été moins nombreux, j'ai depuis refait quelques tests avec un noyau 3.4-rc7 pendant lesquels je n'ai noté aucun ennui, les "cp -dpR" ont parfaitement fonctionné malgré les plus de 80Go à recopier (#500 000 répertoires et plus de 2 000 000 fichiers). 
J'ai mis pour le moment mon répertoire personnel (que je sauvegarde souvent) sur une partition en RAID1 DM+BTRFS. Les résultats sont pour le moment excellents, l'affichage de photos me semble beaucoup plus rapide qu'avant malgré les 15 à 19Mo de chaque photo.

Un autre test fait sur mon répertoire HOME (maintenant en BTRFS) recopié pour sauvegarde dans une baie externe : 
Environ 16 Go avec  #5700 répertoires et #57000 fichiers (Pas mal de fichiers photo RAW et JPG de 10 à 15Mo chacun) en un peu moins de 4 minutes soit une vitesse moyenne de # 66Mo/seconde comprenant donc lecture sur BTRFS et écriture sur une partition LVM de la baie. 
Ainsi la copie de sauvegarde devient (presque) un plaisir.