Optimisation des filesystems extX et du RAID sous Linux

Software version	Kernel 2.6.32+
Operating System	Red Hat 6.3 Debian 7
Website	Kernel Website
Last Update	13/02/2013
Others

1 Introduction

Toutes les opérations de fichiers sur Linux est géré par VFS. La couche VFS est une interface kernel commune pour les applications afin d'accéder à des fichiers. VFS lui s'occupe du dialogue avec les différents drivers. L'inode et dentry cache est gérer par VFS également. VFS est donc capable de gérer via une interface commune différents type de filesystems, même réseaux.

Pour voir la liste des drivers filesystems chargés et donc utilisable par VFS :

cat

> cat /proc/filesystems nodev sysfs nodev rootfs nodev bdev nodev proc nodev cgroup nodev cpuset nodev tmpfs nodev devtmpfs nodev debugfs nodev securityfs nodev sockfs nodev pipefs nodev anon_inodefs nodev devpts nodev ramfs nodev hugetlbfs nodev pstore nodev mqueue nodev usbfs ext4 nodev binfmt_misc vfat

2 ExtX

Les filesystems extX sont découpés en groupes de blocks qui ont tous la même structure et leur permettent de limiter la fragmentation. Chaque groupe de block a sa propre table d'inodes. Le fait que chaque groupe gère sa propre table, permet de réduire considérablement les temps d'accès. Lorsque le kernel veut allouer des blocks de données sur un fichier, il essayera de les allouer sur le même groupe de blocks.

Pour expliquer un peu le schema ci dessus :

• Superblock : groupe de block 0, il contient le superblock primaire, tandis que les autres groupes contiennent une sauvegarde de ce superblock
• FS/Group descriptor : donnes les informations sur la structure du groupe de blocks
• Block Bitmap : permet de mettre ou enlever des bits pour chaque block libre ou en cours d'utilisation. Par exemple, avec un filesystem ayant des blocks de 4K, la taille du groupe de blocks est limité à 4096*8 blocks.
• Inode Bitmap : permet de mettre ou enlever des bits pour chaque inode libre ou en cours d'utilisation.
• Inode Table : L'espace ou sont stockés les inodes. Chaque inode corresponds à 128 bytes sur 8 inodes/K.

Comme pour tout filesystem, le premier block correspond au secteur de boot.

3 La fragmentation

La fragmentation est source de gros ralentissement sur des filesystems tel que fat32, mais ne l'est pas pour extX. Bien que des utilitaires de défragmentation existent sur extX, il ne sont normalement pas nécessaire dû à la nature de ce filesystem. La fragmentation ralenti les performances sur les lectures séquentielles du fait que la tête de lecture du disque doit se déplacer énormément. Le kernel s'occupe de réarranger les données pour minimiser les fragmentations.

Lorsque qu'il y a une allocation de fichier sur de l'extX, le filesystem va pré-allouer de l'espace supplémentaire jusqu'à 8 blocks de plus pour limiter la fragmentation. dans le cas ou ce n'est pas possible, une allocation sur le même groupe de blocks sera faite et donc il n'y aura qu'une minime fragmentation.

3.1 Obtenir les informations de fragmentation

Pour voir s'il y a de la fragmentation sur un filesystem monté :

dumpe2fs

> dumpe2fs /dev/sda1 Groupe 1 : (Blocs 8193-16384) [ITABLE_ZEROED] Checksum 0x6346, i-noeuds non utilisés 2007 superbloc Secours à 8193, Descripteurs de groupes à 8194-8194 Blocs réservés GDT à 8195-8450 Bitmap de blocs à 260 (bg #0 + 259), Bitmap d'i-noeuds à 276 (bg #0 + 275) Table d'i-noeuds à 542-792 (bg #0 + 541) 5872 blocs libres, 2007 i-noeuds libres, 1 répertoires, 2007 i-noeuds non utilisés Blocs libres : 8577-8702, 8706-9216, 10043-10044, 10235-12288, 12293-12997, 13176, 13200, 13284, 13912-16382 I-noeuds libres : 2010-4016 Groupe 2 : (Blocs 16385-24576) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x8215, i-noeuds non utilisés 2008 Bitmap de blocs à 261 (bg #0 + 260), Bitmap d'i-noeuds à 277 (bg #0 + 276) Table d'i-noeuds à 793-1043 (bg #0 + 792) 3971 blocs libres, 2008 i-noeuds libres, 0 répertoires, 2008 i-noeuds non utilisés Blocs libres : 20481-20608 I-noeuds libres : 4017-6024

• A la ligne 8 : il y a de la fragmentation car il y a quelques blocks non contigus sur le groupe de blocks
• A la ligne 15 : il n'y a pas de fragmentation sur le groupe de blocks

Vous pouvez utiliser la commande filefrag pour voir la fragmentation sur un fichier :

filefrag

> filefrag -v /etc/passwd Filesystem type is: ef53 File size of /etc/passwd is 1405 (1 block, blocksize 4096) ext logical physical expected length flags 0 0 3219179 1 eof /etc/passwd: 1 extent found

Et pour un filesystem démonté, vous connaissez la commande fsck.

3.2 Tuning de fragmentation

Par défaut, lorsque vous formattez une partition en extX, 5% de la capacité de celle ci est réservée à la gestion du FS afin d'éviter la fragmentation. Il existe une option lors du mkfs pour spécifier le pourcentage souhaité pour cette gestion :

mke2fs

mke2fs -m <pourcentage_reserve>

Si votre filesystem est déjà créer, vous pouvez changer la taille de cette allocation :

tune2fs

tune2fs -m <pourcentage_reserve>

Notes

Si vous n'utilisez pas assez d'espace réservé, vous aurez une dégradation des performances, si vous en utilisez trop, vous perdrez de l'espace disque inutilement.

4 Les Journaux

Un des facteurs les plus important sur la baisse des performances en ext3 est le journal. Je précise qu'il n'y a pas de journaux en ext2. Il existe 3 type de journaux :

• Ordered : les metadatas sont journalisées
• Journal : les données et les métadatas sont journalisées
• Writeback : les metadatas sont journalisées sans garantie

Lors d'une demande écriture, des données qui doivent être écrites correspondent aux données elles même et aux journaux. Il y a donc 2 écritures pour une demande.

Pour monter une partition en choisissant le journal :

mount

mount -o data=<journal_type>

Sur la plus part des Linux, c'est le mode ordered qui est utilisé. Dans ce mode, les données devant être écrites le seront de telle sorte que les blocks de données liées aux metadatas sont écrite sur le disque avant que les metadatas soient écrites dans le journal. Cela permet d'avoir une consistance entre les journauux et les données. Toutes données listées présente dans le journal se trouvent donc sur le disque.
Là ou l'on perd le moins de performances en extX, c'est le writeback. Dans ce mode le filesystem ne fait pas d'efforts pour mettre en ordre les données sur le disque. Les données sont d'abord écrites sur le journal avant d'être écrites sur le disque.

Lorsque le journal est activé, les metadatas et les données sont journalisées. Ceci double le compteur de visites lorsqu'un journal interne est utilisé. Cependant, lorsque 'data=journal', pleins de petites écritures sont jointes pour l'écriture sur disque afin d'avoir une écriture sur disque linéaire, qui améliorera les performances et arrangera correctement les données.

L'avantage du journal est de réduire le temps de check disque après un crash de la machine. Et 'data=journal' évite les lenteurs sur les écritures aléatoires. Le mode journal est donc le mode recommandé.

4.1 Tuning de journaux

4.1.1 Partition séparée

Afin d'avoir de meilleures performances sur le journal, il est possible de l'agrandir et de choisir la taille des blocks (qui peuvent aller de 1024 à 102400). Par exemple, voici comment spécifier une taille :

mke2fs

mke2fs -b 4096 -J size=16 /dev/sda1

La taille du journal dépends de la taille du filesystem et du taux d'écriture. Si vous souhaitez gagner des performances, il faut mettre le journal sur une partition à part :

• Le Data journaling est une option de montage, donc le journal et le filesystem doivent avoir la même taille de blocks
• La partition entière doit être dédiée au journal

Pour créer un journal sur une autre partition, voici comment faire :

• Démontage du filesystem :

umount

umount /mnt/datas

• On récupère la taille du journal :

dumpe2fs

> dumpe2fs /dev/sda1 | grep -i 'journal size' dumpe2fs 1.42.5 (29-Jul-2012) Journal size: 128M

On peut voir que la taille du journal est de 128M.

• On supprime le journal actuel de la partition :

tune2fs

tune2fs -f -O ^has_journal /dev/sda1

• On créer un nouveau journal sur une autre partition, qu'il faudra créer au préalable (donc 128M) :

mke2fs

mke2fs -O journal_dev -b 4096 /dev/sdb1

• On met à jour le filesystem de la première partition pour lui informer du nouveau journal :

tune2fs

tune2fs -j -J device=/dev/sdb1 /dev/sda1

4.1.2 Augmenter les périodes d'écriture des journaux

Il existe une option permettant de dire au driver ext3/4 tout les combien de temps il doit écrire dans le journal. Par défaut c'est 5 secondes, mais il est possible d'augmenter cette valeur, sous peine de perdre des données. Plus la valeur est basse, plus on garanti l'intégrité des données, mais on réduit les performances. Si la valeur passée est à 0, se sera alors les 5 secondes par défaut qui seront prises, mais si vous souhaitez changer cette valeur :

mount

mount -o commit=15 /dev/sda1 /mnt/datas

5 noatime

Il est possible de désactiver les temps d'accès sur les fichiers. C'est à dire que par défaut, à chaque fois que vous faites un accès à un fichier, il est enregistré la date d'accès sur ce dernier. S'il y a beaucoup d'accès concurrent sur une partition, ça finit par se sentir énormément. C'est pourquoi vous pouvez le désactiver si cette fonctionnalité ne vous est pas utile. Dans votre fstab, rajoutez l'option noatime :

/etc/fstab

/dev/mapper/vg-home /home ext4 defaults,noatime 0 2

Il est possible d'utiliser la même fonctionnalité pour les dossiers :

/etc/fstab

/dev/mapper/vg-home /home ext4 defaults,noatime,nodiratime 0 2

6 Les locks contentions

Les applications nécessitant les accès exclusifs à un fichier font généralement une demande de lock, afin de savoir s'il est déjà utilisé ou non. C'est généralement le cas pour les partages réseaux pour être sur qu'il n'y aura pas de modifications à 2 endroits simultanément. Lorsqu'une application en a fini avec un fichier, elle libère le lock, ce qui permettra à d'autres applications d'y avoir de nouveau accès. Les mécanismes de lock sont largement utilisés par les bases de données par exemple.

Il existe 3 types de locks :

• Applicative : Les applicatives sont gérées par l'application et correspondent à un fichier situé quelque part sur le système. C'est à l'application de gérer le système de lock.
• Advisory : Si l'on souhaites que ce soit le kernel qui gère le système de lock, c'est possible. Cependant en mode advisory, il est possible de coder un soft pour passer au travers de ce lock.
• Mandatory : Si l'on veut aller plus loin et que n'importe quelle application ai la contrainte du lock sans que ce soit codé dans le programme, on va alors demander au kernel de le gérer.

Pour le lock mandatory sur un fichier, il va falloir utiliser les SGID bit sur le group :

chmod

chmod g+s-x fichier

Pour que cela fonctionne, il faudra également que la partition en question ai l'option d'activée :

mount

mount -oremount,mand /mnt/datas

Vous pouvez obtenir les informations surl es locks kernel comme ceci :

cat

> cat /proc/locks 1: POSIX ADVISORY WRITE 24473 00:0e:250393 0 EOF 2: POSIX ADVISORY READ 23603 fd:02:1704266 128 128 3: POSIX ADVISORY READ 23603 fd:02:1704249 1073741826 1073742335 4: POSIX ADVISORY READ 23603 fd:02:1704823 1073741826 1073742335 5: POSIX ADVISORY READ 23603 fd:02:1704243 1073741826 1073742335 6: POSIX ADVISORY READ 23603 fd:02:1704259 128 128 7: POSIX ADVISORY READ 23603 fd:02:1704217 1073741826 1073742335 8: POSIX ADVISORY WRITE 23603 fd:02:1704846 0 EOF 9: POSIX ADVISORY WRITE 10347 fd:02:3015193 1073741824 1073742335 10: POSIX ADVISORY WRITE 10347 fd:02:3015194 1073741824 1073742335 11: POSIX ADVISORY READ 10347 fd:02:3015933 128 128 12: POSIX ADVISORY READ 10347 fd:02:3015252 1073741826 1073742335 13: POSIX ADVISORY READ 10347 fd:02:3015922 128 128 14: POSIX ADVISORY READ 10347 fd:02:3015240 1073741826 1073742335 15: POSIX ADVISORY WRITE 10347 fd:02:3015192 0 EOF 16: FLOCK ADVISORY WRITE 3376 fd:02:2359374 0 EOF 17: FLOCK ADVISORY WRITE 3376 fd:02:2359366 0 EOF 18: FLOCK ADVISORY WRITE 3376 fd:02:2359348 0 EOF 19: FLOCK ADVISORY WRITE 3376 fd:02:2359339 0 EOF 20: FLOCK ADVISORY WRITE 3376 fd:02:2228383 0 EOF 21: FLOCK ADVISORY WRITE 3376 fd:02:2228252 0 EOF 22: POSIX ADVISORY WRITE 3376 00:11:11525 0 EOF [...]

La 6ème colonne se lit de la façon suivante : MAJOR-DEVICE:MINOR-DEVICE:INODE-NUMBER. Grace au numero de PID, il est facile de retrouver le processus qui fait de la contention sur un fichier (5ème colonne). Si vous avez besoin de connaitre l'inode d'un fichier :

ls

> ls --inode fichier 1704256 fichier

Et inversement, si vous avez besoin de trouver un fichier depuis un inode :

find

find / -inum <inode_number> -print

Pour plus d'informations, consultez la documentation officielle.

7 RAID

Je ne parlerais des différents Raid, mais vous laisserais plutôt Wikipedia pour cela. Pour l'utilisation d'un RAID software sous Linux, je vous recommande cette documentation. Nous parlerons plutôt des performances puisque c'est le sujet ici. Le RAID 0 est le plus performant de tous les raid, mais il connait évidement ses problèmes de sécurité des données lors de la perte d'un disque.

Le MTBF (Mean Time Between Failure) est également important sur les RAID. C'est une estimation du bon fonctionnement du RAID avant qu'un disque soit détecté comme défaillant.

7.1 Chunk size

La "Chunck size" (ou taille du stripe ou encore element size pour certains revendeurs) est le nombre (en taille de segments (KiB)) de données écrites ou lues pour chaque périphérique avant le déplacement sur un autre segment. L'algorithme de déplacement utilisé est le Round Robin. La chunk size doit être un entier, multiple de la taille d'un block. Plus la taille des chunk est grande, plus la vitesse d'écriture est rapide sur les données de très grosse capacité, mais inversement est lente sur les petites données. Si la taille moyenne est requêtes IO est plus petite que la taille d'un chunck, la requête sera alors placée sur un seul disque du RAID, annulant tout les avantages du RAID. Réduire la taille de la chunck size, découpera les gros fichiers en plus petits qui seront répartis sur plusieurs disques ce qui améliorera les performances. Cependant le temps de positionnement des chunk sera réduit. Certains matériels ne permettent pas l'écriture tant qu'un stripe n'est pas complet, annulant cet effet de latence de positionnement.

Une bonne règle pour définir la chunk size est de diviser environ la taille des opération IO par le nombre de disques sur le RAID (enlevez les disques de parités si RAID5 ou 6).

Notes

Petit rappel : Raid 0 : Pas de parité Raid 1 : Pas de parité Raid 5 : 1 disque de parité Raid 6 : 2 disque de parité Raid 10 : Pas de disques de parité

Si vous n'avez aucunes idées de vos IO, prenez une valeur entre 32KB et 128KB en prenant un multiple de 2KB (ou 4KB si vous avez des tailles de blocks plus grandes). La chunk size (taille du stripe) est un facteur important sur les performances de votre RAID. Si le stripe est trop large, le raid peut avoir un "hot spot" qui sera le disque qui recevra le plus d'IO et réduira les performances de votre RAID. Il est évident que les meilleures performances sont lorsque les données sont éclatées sur tous les disques. La bonne formule est donc :

Chunk size = average request IO size (avgrq-sz) / number of disks

Pour obtenir la taille des requêtes moyennes, je vous invite à faire un tour sur la documentation sur Systat ou l'on parle d'Iostat et de Sar.

• Pour voir la chunk size sur un RAID (ici md0) :

> cat /sys/block/md0/md/chunk_size 131072

Il est donc ici de 128KB.

Voici une autre façon de le voir :

cat

> cat /proc/mdstat Personalities : [raid10] md0 : active raid10 sdc2[3] sda2[1] sdb2[0] sdd2[2] 1949426688 blocks super 1.0 128K chunks 2 near-copies [4/4] [UUUU]  unused devices: <none>

Ou bien encore :

mdadm

> mdadm --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Sat May 12 09:35:34 2012 Raid Level : raid10 Array Size : 1949426688 (1859.12 GiB 1996.21 GB) Used Dev Size : 974713344 (929.56 GiB 998.11 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent   Update Time : Thu Aug 30 12:53:20 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0   Layout : near=2 Chunk Size : 128K  Name : N7700:2 UUID : 1a83e7dc:daa7d822:15a1de4d:e4f6fd19 Events : 64   Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 2 1 active sync /dev/sda2 2 8 50 2 active sync /dev/sdd2 3 8 34 3 active sync /dev/sdc2

• Il est possible de définir la chunk size à la création du RAID avec l'argument -c ou --chunk. Nous allons également voir comment le calculer au mieux. Utilisons d'abord iostat pour récupérer la valeur avgrq-sz :

iostat

> iostat -x sda 1 5   avg-cpu:  %user  %nice %system %iowait  %steal  %idle 0,21 0,00 0,29 0,05 0,00 99,45 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm  %utilsda 0,71 1,25 1,23 0,76 79,29 15,22 47,55 0,01 2,84 0,73 0,14  avg-cpu:  %user  %nice %system %iowait  %steal  %idle 0,00 0,00 0,00 0,00 0,00 100,00   Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm  %util sda 0,00 0,00 1,00 0,00 16,00 0,00 16,00 0,00 1,00 1,00 0,10   avg-cpu:  %user  %nice %system %iowait  %steal  %idle 0,00 0,00 0,00 0,00 0,00 100,00

Faisons ensuite le calcul pour obtenir la chunk size en KiB :

echo

> echo "47.55*512/1024" | bc -l 23.77500000000000000000

Nous devons ensuite diviser cette valeur par le nombre de disques (admettons 2) et l'arrondir au multiple de 2 plus proche :

Chunk Size(KB) = 23.775/2 = 11.88 ? 8

Ici la chunk size à mettre est de 8, puisque c'est le multiple de 2 qui se rapproche le plus de 11.88.

WARNING

Rappelez vous qu'il n'est pas conseillé de descendre en dessous de 32K !

Pour créer un raid 0 en définissant la chunk size :

mdadm -C /dev/md0 -l 0 -n 2 --chunk-size=32 /dev/sd[ab]1

7.2 Stride

Le Stride est un paramètre que l'on passe lors de la construction d'un RAID qui permet d'optimiser la façon dont le filesystem va placer ses blocks données sur les disques avant de passer aux suivants. Avec de l'extXn on peut optimiser en utilisant l'option -E qui correspond au nombre de filesystems blocks dans un chunk. Pour calculer le stride :

Stride = chunk size / block size

Pour un raid 0 ayant un chunk size de 64KiB (64 KiB / 4KiB = 16) par exemple :

mkfs.ext4

mkfs.ext4 -b 4096 -E stride=16 /dev/mapper/vg1-lv0

Certains contrôleurs disques font une abstraction physique des groupes de blocks rendant impossible au kernel de les connaitre. Voici un exemple pour voir la taille d'un stride :

dumpe2fs

> dumpe2fs /dev/mapper/vg1-lv0 | grep -i stride dumpe2fs 1.42 (29-Nov-2011) RAID stride: 16

Ici, la taille est 16 KiB.

Pour calculer le stride, il existe un site web également : http://busybox.net/~aldot/mkfs_stride.html

7.3 Le Round Robin

Les RAID sans parités permettent de segmenter les données à travers de multiple disques pour augmenter les performances en utilisant l'algorithme Round Robin. La taille des segments est définit à la création du RAID et fait référence à la chunk size.
La taille d'un RAID est définit par le disque le plus petit lors de la création du RAID. La taille peut varier dans le futur si tous les disques sont remplacés par des disques de plus grosse capacité. Une resynchronisation des disques se fera et le filesystem pourra être étendu.

Donc pour le tuning du Round Robin, il vous faut correctement tuner la chunk size et le stride pour que l'utilisation de l'algorithme soit optimale ! C'est tout :-)

7.4 Les RAIDs à parité

Une des grosses contraintes de performances des RAID 5 et 6 est le calcul des parités. Pour que les données y soient écrites, il faut que le calcul de parité soit effectué sur le raid au préalable. et ce n'est seulement ensuite que la parité et les données peuvent y être écrites.

WARNING

Evitez les RAID 5 et 6 si l'écriture de vos données représentent + de 20% de l'activité

Chaque mise à jour de données requiert 4 opérations de type IO :

1. Les données à mettre à jour sont d'abord lues des disques
2. Mise à jour des nouvelles données (mais la parité n'est pas encore correcte)
3. Lecture des blocks du même stripe et calcul de parité
4. Écriture définitive des nouvelles données sur disques et de la parité

En RAID 5, il est conseillé d'utiliser le cache du stripe :

echo

echo 256 > /sys/block/md0/md/stripe_cache_size

Pour plus d'informations sur les optimisations des RAID : http://kernel.org/doc/Documentation/md.txt. Pour la partie optimisation, regardez les paramètres suivants :

• chunk_size
• component_size
• new_dev
• safe_mode_delay
• sync_speed_{min,max}
• sync_action
• stripe_cache_size

7.5 Le RAID 1

Le driver RAID effectue une écriture dans le bitmap lorsque des changements ont été détectés depuis la dernière synchronisation. Un inconvénient majeure du RAID 1 est lors d'une coupure de courant, puisque celui ci doit se reconstruire intégralement. Avec la 'write-intent' bitmap,seul les parties qui ont changées auront à être synchroniser, ce qui réduit grandement le temps de reconstruction.

Si un disque tombe en panne et est retiré du RAID, md arrête l'effacement des bits dans la bitmap. Si ce même disque est de nouveau introduit dans le RAID, md n'aura qu'à resynchroniser la différence. Lors de la création du RAID, si l'option '--write-intent' bitmap est combinée avec '--write-behind', les requêtes d'écritures vers des périphériques ayant l'option '--write-mostly' n'attendront pas que les requêtes soient complète avant d'écrire sur le disque. L'option '--write-behind' peut être utiliser pour les RAID1 avec liaisons lentes.

Les nouvelles matrices mdraid prennent en charge l'utilisation de write intent bitmaps. Ceci aide le système à identifier les parties problématiques d'une matrice ; ainsi, au cas où il se produirait un arrêt incorrect, les parties problématiques devront être resynchronisées, et non le disque entier. Cela permet de réduire de manière drastique le temps requis pour effectuer une resynchronisation. Des matrices nouvellement créées auront automatiquement un write intent bitmap ajouté lorsque possible. Par exemple, les matrices utilisées comme swap et les matrices de très petite taille (telles que les matrices /boot) ne bénéficieront pas de l'obtention de write intent bitmaps. Il est possible d'ajouter write intent bitmap aux matrices existant précédemment une fois que la mise à jour sur le périphérique est terminée via la commande mdadm --grow. Cependant, write intent bitmaps n'encourt pas d'impact sur la performance (environ 3-5% sur un bitmap d'une taille de 65536, mais peut augmenter jusqu'à 10% ou plus sur des bitmaps de plus petite taille, tels que 8192). Cela signifie que si write intent bitmap est ajouté à une matrice, il est préférable de conserver la taille relativement grande. La taille recommandée est 65536.

Pour voir si un RAID est bien persistant :

mdadm

> mdadm --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Sat May 12 09:35:34 2012 Raid Level : raid10 Array Size : 1949426688 (1859.12 GiB 1996.21 GB) Used Dev Size : 974713344 (929.56 GiB 998.11 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent  Update Time : Thu Aug 30 16:43:17 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0   Layout : near=2 Chunk Size : 128K   Name : N7700:2 UUID : 1a83e7dc:daa7d822:15a1de4d:e4f6fd19 Events : 64   Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 2 1 active sync /dev/sda2 2 8 50 2 active sync /dev/sdd2 3 8 34 3 active sync /dev/sdc2

Pour ajouter le write intent bitmap (interne) :

mdadm

mdadm /dev/md0 --grow --bitmap=internal

Pour ajouter le write intent bitmap (externe) :

mdadm

mdadm /dev/md0 --grow --bitmap=/mnt/mon_fichier

Et pour le retirer :

mdadm

mdadm /dev/md0 --grow --bitmap=none

Pour définir le disque lent et celui le plus rapide :

mdadm

mdadm -C /dev/md0 -l1 -n2 -b /tmp/md0 --write-behind=256 /dev/sdal --write-mostly /dev/sdbl