Matriz RAID: não pode acessar arquivos em uma partição, recebendo erro de entrada / saída

Question

Estou atingindo um erro de acesso com parte de uma matriz de ataque e preciso de ajuda para solucionar isso.

Histórico: Várias partições de ataque vivem em 4 discos. Quatro dias atrás, alguns ruídos foram ouvidos na estação de trabalho, e o utilitário GUI ubuntu mostrou alguns setores defeituosos, mas as coisas eram verdes. Ontem (qui, 17 de abril) fomos atingidos por uma queda de energia e uma strong reinicialização. Após a reinicialização rígida, o sistema aparece e monta a maioria das partições de raid, mas uma grande crítica (contendo / home) está causando erros de entrada / saída.

bpbrown@eguzki:/$ ls home
ls: cannot access home: Input/output error
bpbrown@eguzki:/$ 

Estamos no Ubuntu 12.04 e, devido à perda de /home , estamos apenas na linha de comando.

Na reinicialização, mdadm mostrou que a matriz estava sendo ressincronizada; que parece ter sido concluído, mas ainda sem sorte em acessar /home . Aqui estão os resultados 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:/$ 

e aqui está o 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:/$ 

Desmontar e remontar /dev/md10 não parece ajudar, embora eu tenha perdido uma etapa na montagem correta da matriz de ataque.

Se for útil, aqui está o conteúdo 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:/$ 

Atualização de 23 de abril: Tentei montar o sistema de arquivos diretamente novamente e recebi uma mensagem de erro possivelmente útil. Aqui está uma versão curta, omitindo alguns dos traços de chamada:

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:/$

Agradeço antecipadamente por qualquer sugestão sobre como proceder,

- Ben

    

Answer 1

Acontece que o problema raiz aqui era de fato a corrupção do sistema de arquivos XFS durante o desligamento impuro. Pior, o sistema de arquivos XFS tinha um arquivo de log não resolvido, levando aos seguintes avisos:

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.

A montagem ainda estava falhando, então continuamos com xfs_repair -L . Isso funcionou rapidamente (menos de 5 minutos) e, apesar dos terríveis avisos, a partição /home foi montada e legível imediatamente depois.

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:/$

Até onde podemos dizer, o sistema é funcional e não sofreu perda de dados críticos.

O Cray acabou tendo alguma documentação útil sobre xfs_check e xfs_repair para alguém novo nessas ferramentas como eu, então incluí seu link no caso de alguém encontrar esses problemas pela primeira vez:

link

Felicidades e obrigado a todos que leram e pensaram em ideias

- Ben