Baie RAID: impossible d'accéder aux fichiers sur une partition, obtenant une erreur d'entrée / sortie
Je rencontre une erreur d'accès avec une partie d'un tableau RAID et j'ai besoin d'aide pour résoudre ce problème.
Historique: Plusieurs partitions de raid vivent sur 4 disques. Il y a quatre jours, des bruits de cliquetis ont été entendus du poste de travail et l'utilitaire de disque GUI ubuntu a montré des secteurs défectueux, mais les choses étaient autrement vertes. Hier (jeudi 17 avril), nous avons été touchés par une panne de courant et un redémarrage forcé. Après le redémarrage dur, le système arrive et monte la plupart des partitions de raid, mais une grande critique (contenant/home) génère des erreurs d'entrée/sortie.
bpbrown@eguzki:/$ ls home
ls: cannot access home: Input/output error
bpbrown@eguzki:/$
Nous sommes dans Ubuntu 12.04, et en raison de la perte de /home, nous sommes en ligne de commande uniquement.
Au redémarrage, mdadm a montré que la baie était en cours de resynchronisation; qui semble avoir terminé, mais toujours pas de chance d'accéder à /home. Voici les résultats de mdadm:
bpbrown@eguzki:/$ Sudo mdadm -D /dev/md10
/dev/md10:
Version : 0.90
Creation Time : Thu Feb 4 16:49:43 2010
Raid Level : raid5
Array Size : 2868879360 (2735.98 GiB 2937.73 GB)
Used Dev Size : 956293120 (911.99 GiB 979.24 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 10
Persistence : Superblock is persistent
Update Time : Fri Apr 19 10:03:46 2013
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 317df11d:4e2edc70:fa3efedc:498284d3
Events : 0.2121101
Number Major Minor RaidDevice State
0 8 10 0 active sync /dev/sda10
1 8 26 1 active sync /dev/sdb10
2 8 42 2 active sync /dev/sdc10
3 8 58 3 active sync /dev/sdd10
bpbrown@eguzki:/$
et voici mdstat:
bpbrown@eguzki:/$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md1 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
497856 blocks [4/4] [UUUU]
md8 : active raid5 sda8[0] sdb8[1] sdc8[2] sdd8[3]
5301120 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md6 : active raid5 sda6[0] sdb6[1] sdc6[2] sdd6[3]
20530752 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md7 : active raid5 sda7[0] sdc7[2] sdd7[3] sdb7[1]
5301120 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md5 : active raid5 sda5[0] sdd5[3] sdc5[2] sdb5[1]
5301120 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md10 : active raid5 sda10[0] sdc10[2] sdd10[3] sdb10[1]
2868879360 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
bpbrown@eguzki:/$
Démontage et remontage /dev/md10 ne semble pas aider, même si j'ai peut-être manqué une étape dans le montage correct du tableau de raid.
Si utile, voici le contenu de /etc/fstab:
bpbrown@eguzki:/$ more /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/md5 / reiserfs relatime 0 1
/dev/md1 /boot reiserfs notail,relatime 0 2
/dev/md10 /home xfs relatime 0 2
/dev/md8 /tmp reiserfs relatime 0 2
/dev/md6 /usr reiserfs relatime 0 2
/dev/md7 /var reiserfs relatime 0 2
/dev/sda9 none swap pri=1 0 0
/dev/sdb9 none swap pri=1 0 0
/dev/sdc9 none swap pri=1 0 0
/dev/sdd9 none swap pri=1 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
bpbrown@eguzki:/$
Mise à jour du 23 avril: J'ai essayé de monter le système de fichiers de nouveau directement et j'ai reçu un message d'erreur peut-être utile. Voici une version courte, en omettant une partie de la trace d'appel:
bpbrown@eguzki:/$dmesg | tail
[ 788.335968] XFS (md10): Mounting Filesystem
[ 788.516845] XFS (md10): Starting recovery (logdev: internal)
[ 790.082900] XFS: Internal error XFS_WANT_CORRUPTED_GOTO at line 1503 of file /build/buildd/linux-3.2.0/fs/xfs/xfs_alloc.c. Caller 0xffffffffa0226837
[ 790.082905]
[ 790.083004] Pid: 3211, comm: mount Tainted: P O 3.2.0-38-generic #61-Ubuntu
[ 790.083010] Call Trace:
<omitted for brevity>
[ 790.084139] XFS (md10): xfs_do_force_shutdown(0x8) called from line 3729 of file /build/buildd/linux-3.2.0/fs/xfs/xfs_bmap.c. Return address = 0xffffffffa0236e52
[ 790.217602] XFS (md10): Corruption of in-memory data detected. Shutting down filesystem
[ 790.217654] XFS (md10): Please umount the filesystem and rectify the problem(s)
[ 790.217761] XFS (md10): xfs_imap_to_bp: xfs_trans_read_buf() returned error 5.
[ 790.217775] XFS (md10): xlog_recover_clear_agi_bucket: failed to clear agi 5. Continuing.
<last 2 lines repeat 8 times>
[ 790.388209] XFS (md10): Ending recovery (logdev: internal)
bpbrown@eguzki:/$
Merci d'avance pour toute suggestion sur la marche à suivre,
--Ben
Il s'avère que le problème racine ici était en effet la corruption du système de fichiers XFS lors de la mise hors tension impure. Pire encore, le système de fichiers XFS avait un fichier journal non résolu, ce qui a provoqué les avertissements suivants:
bpbrown@eguzki:/$ Sudo xfs_check /dev/md10
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair. If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
Le montage échouait toujours, nous avons donc procédé à xfs_repair -L. Cela a fonctionné rapidement (moins de 5 minutes) et malgré les avertissements désastreux, le /home la partition était montable et lisible immédiatement après.
bpbrown@eguzki:/$ Sudo xfs_repair -L /dev/md10
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
agi unlinked bucket 34 is 50978 in ag 1 (inode=536921890)
<...>
Phase 7 - verify and correct link counts...
resetting inode 97329 nlinks from 2 to 3
resetting inode 536921890 nlinks from 0 to 2
done
bpbrown@eguzki:/$
Pour autant que nous puissions en juger, le système est fonctionnel et n'a subi aucune perte de données critique.
Cray a fini par avoir une documentation utile sur xfs_check et xfs_repair pour quelqu'un qui ne connaît pas ces outils comme moi, j'ai donc inclus son lien au cas où quelqu'un d'autre rencontrerait ces problèmes pour la première fois:
http://docs.cray.com/books/S-2377-22/html-S-2377-22/z1029470303.html
Bravo, et merci à tous ceux qui lisent ceci et pensent à des idées,
--Ben