Plantages xfs_repair phase 6 malgré différents arguments

Support Debian
#1

Bonjour à tous,

Mon problème à la base était de réparer une partition /home (cryptée via Luks à la base) de mon serveur Debian (version 2.6.26-2-686, vieille car il s’agit d’une config “figée” à laquelle je ne touche jamais). Je me suis aperçu que la partition avait besoin d’être réparée au cours d’une opération anodine :

[code]# cd /

du -shc *[/code]

Pour info il s’agit d’une très grosse partition RAID (résultant de 4 disques de 1 To en RAID 5, soit 3 To utiles).
J’ai obtenu une seule et unique erreur pendant le scan des répertoires (sur un très gros fichier dont j’ai heureusement un backup) :

J’ai démonté proprement la partition /home (ce qui n’a pas été simple, mais passons, j’ai finalement réussi), puis ensuite j’ai essayé ceci :xfs_repair /dev/mapper/decrypted
Résultat : ça a bloqué à cette étape-ci :Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 2150292850 (no data entry): rebuilding rebuilding directory inode 2150292850
Par “bloqué” je veux dire : le process à 99% CPU ou plus pendant plus de 3h, pas d’activité disques visible, et la RAM utilisée par le process bloquée à 2.7 MB sans la moindre variation. J’ai attendu, attendu, puis j’ai fini par être convaincu que xfs_repair était vraiment planté.

J’ai donc relancé la commande suivante (trouvée ici : oss.sgi.com/archives/xfs/2011-07/msg00273.html ) :xfs_repair -P /dev/mapper/decrypted
Résultat : ça a bloqué au même endroit dirons-nous (là je n’ai pas attendu plus de 30min, les symptômes étaient exactement les mêmes) :Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ...
Là je suis vraiment perdu… que puis-je faire maintenant SVP ?

Merci d’avance pour votre aide. :slightly_smiling:

#2

Suite de mes investigations. Cette personne-ci semblait avoir exactement le même problème que moi : oss.sgi.com/archives/xfs/2009-09/msg00120.html
[ul][li] xfs_repair normal : FAIL chez lui[/li]
[li] xfs_repair -P : FAIL chez lui[/li]
[li] xfs-repair -P -o bhashsize=1024 : Ca a finalement marché chez lui ! :smiley: [/li][/ul]

Comme les deux premiers ont échoué chez moi, j’ai tenté le troisième, plein d’espoir et tout. Or j’obtiens le message suivant :

[code]# xfs_repair -P -o bhashsize=1024 /dev/mapper/decrypted
unknown option -o bhashsize=1024
Usage: xfs_repair [options] device

Options:
-f The device is a file
-L Force log zeroing. Do this as a last resort.
-l logdev Specifies the device where the external log resides.
-m maxmem Maximum amount of memory to be used in megabytes.
-n No modify mode, just checks the filesystem for damage.
-P Disables prefetching.
-r rtdev Specifies the device where the realtime section resides.
-v Verbose output.
-c subopts Change filesystem parameters - use xfs_admin.
-o subopts Override default behaviour, refer to man page.
-t interval Reporting interval in minutes.
-d Repair dangerously.
-V Reports version and exits.
zsh: exit 1 xfs_repair -P -o bhashsize=1024 /dev/mapper/decrypted[/code]
Pourquoi ?.. :mrgreen:

#3

xfs_repair semble ne pas connaître cette option chez toi.

Cette option apparait-elle sur ton manuel ?

Ta version de xfs_repair (xfs-progs) serait-elle trop ancienne ?

Essaye simplement de supprimer le(s) fichier(s) fautif(s) alors que xfs est monté, démonte/remonte.

Si ça coince toujours tu pourrais essayer avec l’option -L.
$ man xfs_repair

-L Force Log Zeroing. Forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data.

#4

Oui, l’option -o apparaît sur mon manuel (lire plus haut, à la fin de mon post précédent).
Il semblerait que ce soit le paramètre bhashsize=1024 qui ne passe pas ?

Ma version de xfs_repair est la 2.9.8.

Concernant les étapes suivantes qui sont un peu plus “radicales” car entraînant la destruction potentielle de données (suppression du fichier, ou encore xfs_repair -L), disons que je préfèrerais faire les choses dans l’ordre, et pour moi il semblerait plus logique de faire d’abord une MAJ de xfs_repair et de l’exécuter avec l’option -o bhashsize=1024 pour voir si ça marche…

#5

Je relis le manuel et me rends compte que je n’avais pas noté l’erreur.

                 bhash=bhashsize
                        overrides  the  default  buffer  cache  hash size. The
                        total number of buffer cache entries are limited to  8
                        times  this  amount. The default size is set to use up
                        the remainder of 75%  of  the  system's  physical  RAM
                        size.

L’option serait donc
-o bhash=1024
et pas
-o bhashsize=1024

Xfs est un système de fichiers particulièrement solide. Le test critique est de savoir s’il se monte. S’il ne se monte pas, le problème est sérieux.
À la lecture de ton message précédent, je vois que tu arrives à le monter.
Je te recommande donc de soulager xfs_repair en supprimant les fichiers fautifs.
La suppression aura également valeur de test :
les fichiers se supprimeront-ils sans problèmes ?

#6

Merci de ta trouvaille et de tes conseils. :slightly_smiling:

J’ai voulu tester quand-même l’option bhash (oui, têtu :mrgreen: ) et… ça a tourné un peu court vu que j’ai obtenu ceci :

# xfs_repair -P -o bhash=1024 /dev/mapper/decrypted Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 zsh: killed xfs_repair -P -o bhash=1024 /dev/mapper/decrypted
Qu’est-ce qui s’est passé ? :119

Pour info, ça me fait la même chose au même endroit avec un bhash=2048 (option recommandée par Eric Sandeen dans le topic que je linkais ci-dessus : oss.sgi.com/archives/xfs/2009-09/msg00124.html ).

Si je n’y arrive pas comme ça, je finirai bien sûr par supprimer le fichier fautif (qui fait 20 Go environ).
Oui, la partition /home se monte sans souci en principe, donc j’espère que cela n’aura pas changé après les xfs_repair… :think:

#7

Et si je bumpais le topic ? :115 :mrgreen:

#8

Voir les caractéristiques de la partition.

xfs_info

(sur partition montée)

Insiste sans options sous-optimisées, xfs est d’une solidité remarquable. Tu peux même te permettre d’interrompre sauvagement les réparations en cours et les reprendre plus tard.

-P Disable prefetching of inode and directory blocks. Use this option if you find xfs_repair gets stuck and stops proceeding. Interrupting a stuck xfs_repair is safe.

xfs_repair may be able to make more repairs on successive runs

Si tu ne veux pas effacer les fichiers, tente de défragmenter.
techpubs.sgi.com/library/tpl/cgi … 194-PARENT

Pour pouvoir défragmenter, il te faut suffisament d’espace.
Voir l’espace libre sur cette partition.

$ df -hT
et par la même occasion
$ df -hiT
(-i comme inode)

[quote]

xfs_check device

device is the disk or volume device for the filesystem.

If no consistency problems were found, xfs_check returns without displaying any output [/quote]
Test de base, montage/démontage.

Dernière extrêmité si tu ne veux toujours pas effacer les fichiers.

techpubs.sgi.com/library/tpl/cgi … 0946920lhj

[quote]
What to Do If xfs_repair Cannot Repair a Filesystem

If xfs_repair fails to repair the filesystem successfully, try giving the same xfs_repair command twice more; xfs_repair may be able to make more repairs on successive runs. If xfs_repair fails to fix the consistency problems in three tries, your next step depends upon where it failed:

If xfs_repair failed in phase 1, you must restore lost files from backups.

If xfs_repair failed in phase 2 or later, you may be able to restore files from the disk by backing up and restoring the files on the filesystem.

If xfs_repair failed in phase 2 or later, follow these steps:

Mount the filesystem read-only using mount -r.

Make a filesystem backup with xfsdump.

Use mkfs.xfs to a make new filesystem on the same disk partition or logical volume.

Restore the files from the backup with xfsrestore.[/quote]
#9

Merci pour ces informations précieuses ! :041 Je crois que j’ai tous les outils pour mener à bien ma réparation maintenant. Je vais regarder cela de très près. Merci encore.

Pour info, voici le résultat des 3 premières commandes que tu m’as données :

[code]# xfs_info /home
meta-data=/dev/mapper/decrypted isize=256 agcount=49, agsize=15229591 blks
= sectsz=512 attr=1
data = bsize=4096 blocks=731029247, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=32768, version=1
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=65536 blocks=0, rtextents=0

df -hT

Filesystem Type Size Used Avail Use% Mounted on
/dev/md1 ext3 3.7G 2.1G 1.5G 58% /
tmpfs tmpfs 249M 0 249M 0% /lib/init/rw
udev tmpfs 10M 944K 9.1M 10% /dev
tmpfs tmpfs 249M 0 249M 0% /dev/shm
/dev/md0 ext2 89M 63M 22M 75% /boot
/dev/sdd3 xfs 466G 379G 88G 82% /mnt/sdd3
/dev/mapper/decrypted
xfs 2.8T 2.5T 258G 91% /home

df -hiT

Filesystem Type Inodes IUsed IFree IUse% Mounted on
/dev/md1 ext3 480K 108K 372K 23% /
tmpfs tmpfs 63K 19 63K 1% /lib/init/rw
udev tmpfs 63K 2.3K 60K 4% /dev
tmpfs tmpfs 63K 1 63K 1% /dev/shm
/dev/md0 ext2 48K 60 48K 1% /boot
/dev/sdd3 xfs 350M 1.6K 350M 1% /mnt/sdd3
/dev/mapper/decrypted
xfs 1.1G 1.3M 1.1G 1% /home[/code]
Si quelqu’un voit quelque chose d’anormal, je suis preneur.

Etant donné que j’ai tous les éléments pour résoudre mon problème, je vais cocher ce topic comme résolu. Merci encore ! :023

#10

Mon message n’etait pas adapté j’ai reouvert un autre fils de discusion.