Il n'empêche, de tous les FS que j'ai testés (ext2, ext3, reiserfs3, xfs, jfs et reiser4), c'est celui qui m'a fait perdre le plus de données, avec 3 plantages non récupérables lors de transferts de gros fichiers (je suis persévérant, non).
J'en ai une tout autre avec le XFS, mais bien plus heureuse...
zero perte de donnée critique depuis 4ans, sauf deux fois (mais j'ai fait sciemment des conneries sur un matériel défaillant).
Il faut prévoir un mini-système avec xfs_repair pour le / :
1 => en cas de plantage, on reboot systématiquement sur celui-là
2 => on monte le / (si ça passe), déplacement de /lost+found en /lost+found-$(date -formatquivabien), démontage
3 => on lance un xfs_repair -n /dev/hda1 (le /) pour tester le niveau de fichier qui seront balancé dans /lost+fount
4 => on lance un xfs_repair /dev/hda1 (pour réparer le sf)
5 => montage du /, rmdir /lost+found, démontage
6 => on reboot
Je recommande l'étape 2 en semi automatique, du style :
mount -o ro /dev/hda1 /mnt/disk
[ -d /mnt/disk/lost+found ] && mount -o rw /mnt/disk && mv /mnt/disk/lost+found /mnt/disk/lost+found-$(date -formatquivabien)
umount /mnt/disk
#ceci est pour éviter de perdre les fichiers balancé dans /lost+found a la dernière vérification (la plus grosse faiblesse du XFS)
L'étape 4 peux être conditionnée par la valeur de retour de xfs_repair -n (qui renvoie un code de retour différent si il y a une erreur ou aucune)
L'étape 5 permet de s'éviter des cheveux blanc, si on a aucun fichier dont xfs_repair ne sait que faire on peux virer le répertoire vide (pas de vérification de contenu, prochaine exécution plus rapide)
En fait le soucis que j'ai rencontré est que il n'existe pas de fsck.xfs (en faire c'est un script/binaire a la con qui fait un return 0) et que xfs_repair refuse certaine fois de vérifier le / en lecture seule, donc j'ai opté pour la version seconde partition (qui permet de limiter les dégats et d'avoir un système de backup au cas où)
Mais c'est intégrable au système a condition de modifier les initscripts qui vont bien (chose que j'ai eu une sainte flemme de faire, mais qui sait, si j'ai le temps...)
Quand a la robustesse du XFS, j'ai vraiment rien trouvé de mieux (a part le JFS de IBM, mais il consomme/ait trop de cpu).
=> résistance au hard lock (carte nvidia qui faisait tout freeze un temps)
=> résistance a la coupure de courrant (reboot hard)
Ceci modulo d'appuyer sagement sur alt+print scr+s pour syncroniser les données sur disque après un changement important.
=> bonne tollérance au syndrome du système de fichier remplis (90% utilisé)
=> très bonne performance en tant que sf dans une partition cryptoloop (aes2048), le pross passe a 100% pour le temps d'écriture, mais en lecture 0% d'utilisation de processeur ou presque (lecture de vidéo/son sans lag ni rien)
Il a tout de même des petites faiblesses :
=> non support de selinux (sans augmenter la taille des inodes, mais ça fait perdre une place folle !!!)
=> fragmention gênante dès qu'on dépasse les 80% d'utilisation
Il faut alors libérer beaucoup de Go sur de grosses partition et défragmenter a coup de xfs_fsr -v /mnt/data (point de montage de la partition montée, mais ça peux se faire en user si le système de fichier appartient a votre uid)
Bref, le XFS c'est du bon, mais faut savoir ce qu'on fait :
=> redémarage rapide après gros problème
=> tollérer que des fichiers partent dans /lost+found en cas de coupure de courrant
(genre les pid et très petits fichier récemments écris)
=> faire des BACKUP !!! (on peux très bien perdre les deux magic block en cas de corruption physique du support)
N'est pas fait pour :
=> les personnes ne sachant par replacer les fichiers a coup de file fichier, vim fichier pour savoir qu'en faire
=> personnes peux consciencieuses qui appuie sur power avant même d'avoir fermé openoffice par exemple (si si ça existe, depuis le bouton power est systématiquement sous clef chez moi)
Bref, XFS c'est SGI, qui est mort ou presque, alors l'intégration de leur système de réparation dans un fsck.xfs j'y crois plus du tout, pour le futur va falloir aller voir plus loin (ZFS ?)
Sinon un petit plus du XFS c'est l'économie de place sur le disque, sur une même partition du XFS stocke plus de fichiers (toutes taille confondue) que de l'ext3
[^] # Re: De la maintenance..
Posté par Raphaël G. (site web personnel) . En réponse à la dépêche Pourquoi Reiser4 n'est toujours pas intégré à Linux. Évalué à 4.
J'en ai une tout autre avec le XFS, mais bien plus heureuse...
zero perte de donnée critique depuis 4ans, sauf deux fois (mais j'ai fait sciemment des conneries sur un matériel défaillant).
Il faut prévoir un mini-système avec xfs_repair pour le / :
1 => en cas de plantage, on reboot systématiquement sur celui-là
2 => on monte le / (si ça passe), déplacement de /lost+found en /lost+found-$(date -formatquivabien), démontage
3 => on lance un xfs_repair -n /dev/hda1 (le /) pour tester le niveau de fichier qui seront balancé dans /lost+fount
4 => on lance un xfs_repair /dev/hda1 (pour réparer le sf)
5 => montage du /, rmdir /lost+found, démontage
6 => on reboot
Je recommande l'étape 2 en semi automatique, du style :
mount -o ro /dev/hda1 /mnt/disk
[ -d /mnt/disk/lost+found ] && mount -o rw /mnt/disk && mv /mnt/disk/lost+found /mnt/disk/lost+found-$(date -formatquivabien)
umount /mnt/disk
#ceci est pour éviter de perdre les fichiers balancé dans /lost+found a la dernière vérification (la plus grosse faiblesse du XFS)
L'étape 4 peux être conditionnée par la valeur de retour de xfs_repair -n (qui renvoie un code de retour différent si il y a une erreur ou aucune)
L'étape 5 permet de s'éviter des cheveux blanc, si on a aucun fichier dont xfs_repair ne sait que faire on peux virer le répertoire vide (pas de vérification de contenu, prochaine exécution plus rapide)
En fait le soucis que j'ai rencontré est que il n'existe pas de fsck.xfs (en faire c'est un script/binaire a la con qui fait un return 0) et que xfs_repair refuse certaine fois de vérifier le / en lecture seule, donc j'ai opté pour la version seconde partition (qui permet de limiter les dégats et d'avoir un système de backup au cas où)
Mais c'est intégrable au système a condition de modifier les initscripts qui vont bien (chose que j'ai eu une sainte flemme de faire, mais qui sait, si j'ai le temps...)
Quand a la robustesse du XFS, j'ai vraiment rien trouvé de mieux (a part le JFS de IBM, mais il consomme/ait trop de cpu).
=> résistance au hard lock (carte nvidia qui faisait tout freeze un temps)
=> résistance a la coupure de courrant (reboot hard)
Ceci modulo d'appuyer sagement sur alt+print scr+s pour syncroniser les données sur disque après un changement important.
=> bonne tollérance au syndrome du système de fichier remplis (90% utilisé)
=> très bonne performance en tant que sf dans une partition cryptoloop (aes2048), le pross passe a 100% pour le temps d'écriture, mais en lecture 0% d'utilisation de processeur ou presque (lecture de vidéo/son sans lag ni rien)
Il a tout de même des petites faiblesses :
=> non support de selinux (sans augmenter la taille des inodes, mais ça fait perdre une place folle !!!)
=> fragmention gênante dès qu'on dépasse les 80% d'utilisation
Il faut alors libérer beaucoup de Go sur de grosses partition et défragmenter a coup de xfs_fsr -v /mnt/data (point de montage de la partition montée, mais ça peux se faire en user si le système de fichier appartient a votre uid)
Bref, le XFS c'est du bon, mais faut savoir ce qu'on fait :
=> redémarage rapide après gros problème
=> tollérer que des fichiers partent dans /lost+found en cas de coupure de courrant
(genre les pid et très petits fichier récemments écris)
=> faire des BACKUP !!! (on peux très bien perdre les deux magic block en cas de corruption physique du support)
N'est pas fait pour :
=> les personnes ne sachant par replacer les fichiers a coup de file fichier, vim fichier pour savoir qu'en faire
=> personnes peux consciencieuses qui appuie sur power avant même d'avoir fermé openoffice par exemple (si si ça existe, depuis le bouton power est systématiquement sous clef chez moi)
Bref, XFS c'est SGI, qui est mort ou presque, alors l'intégration de leur système de réparation dans un fsck.xfs j'y crois plus du tout, pour le futur va falloir aller voir plus loin (ZFS ?)
Sinon un petit plus du XFS c'est l'économie de place sur le disque, sur une même partition du XFS stocke plus de fichiers (toutes taille confondue) que de l'ext3