RAID-массив: не может получить доступ к файлам на одном разделе, получив ошибку ввода/вывода
Я поражаю ошибку доступа частью массива RAID и нуждаюсь в помощи в поиске и устранении неисправностей этого.
История: Несколько разделов набега живут на 4 дисках. Четыре дня назад некоторый отсчитывающий шум услышали от рабочей станции, и дисковая утилита человечности GUI показала некоторые поврежденные секторы, но вещи были в других отношениях зелеными. Вчера (Thurs, 17 апреля) мы были поражены сбоем питания и "жесткой" перезагрузкой. После "жесткой" перезагрузки система подходит и монтирует большинство разделов набега, но одно большое критическое одно (содержащий / домой) бросает ошибки ввода/вывода.
bpbrown@eguzki:/$ ls home
ls: cannot access home: Input/output error
bpbrown@eguzki:/$
Мы находимся в Ubuntu 12.04, и вследствие потери /home, мы в командной строке только.
На перезагрузке, mdadm показал, что массив повторно синхронизировал; это, кажется, завершилось, но все еще никакая удача в доступе /home. Вот результаты 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:/$
и вот 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:/$
Размонтирование и перемонтирование /dev/md10 кажется, не помогает, хотя я, возможно, пропустил шаг в корректном монтировании массива RAID.
Если полезный, вот содержание /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:/$
Обновление 23 апреля: Испытанное монтирование файловой системы непосредственно снова и получило возможно полезное сообщение об ошибке. Вот короткая версия, опуская часть трассировки вызовов:
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:/$
Заранее спасибо за любые предложения о том, как продолжить двигаться,
- Ben
1 ответ
Оказывается, коренной проблемой здесь действительно было повреждение файловой системы XFS во время нечистого отключения питания. Хуже того, файловая система XFS содержала неразрешенный файл журнала, что приводило к следующим предупреждениям:
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.
Монтирование все еще не удавалось, поэтому мы приступили к xfs_repair -L. Это работало быстро (менее 5 минут), и, несмотря на страшные предупреждения, раздел /home был смонтирован и читаем сразу после этого.
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:/$
Насколько мы можем судить, система функционирует и не потерпела критической потери данных.
Крэй в итоге получил полезную документацию по xfs_check и xfs_repair для кого-то, кто не знаком с этими инструментами, как я, поэтому я включил их ссылку на случай, если кто-нибудь еще столкнется с этими проблемами впервые:
http://docs.cray.com/books/S-2377-22/html-S-2377-22/z1029470303.html
Приветствия и спасибо всем кто читал это и думал об идеях,
- Бен