У меня есть сервер с mdadm raid0:
# mdadm --version
mdadm - v3.1.4 - 31st August 2010
# uname -a
Linux orkan 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux
Один из дисков вышел из строя:
# grep sdf /var/log/kern.log | head
Jan 30 19:08:06 orkan kernel: [163492.873861] sd 2:0:9:0: [sdf] Unhandled error code
Jan 30 19:08:06 orkan kernel: [163492.873869] sd 2:0:9:0: [sdf] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 30 19:08:06 orkan kernel: [163492.873874] sd 2:0:9:0: [sdf] Sense Key : Hardware Error [deferred]
Прямо сейчас в dmesg я вижу:
Jan 31 15:59:49 orkan kernel: [238587.307760] sd 2:0:9:0: rejecting I/O to offline device
Jan 31 15:59:49 orkan kernel: [238587.307859] sd 2:0:9:0: rejecting I/O to offline device
Jan 31 16:03:58 orkan kernel: [238836.627865] __ratelimit: 10 callbacks suppressed
Jan 31 16:03:58 orkan kernel: [238836.627872] mdadm: sending ioctl 1261 to a partition!
Jan 31 16:03:58 orkan kernel: [238836.627878] mdadm: sending ioctl 1261 to a partition!
Jan 31 16:04:09 orkan kernel: [238847.215187] mdadm: sending ioctl 1261 to a partition!
Jan 31 16:04:09 orkan kernel: [238847.215195] mdadm: sending ioctl 1261 to a partition!
Но mdadm не заметил, что диск вышел из строя:
# mdadm -D /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Thu Jan 13 15:19:05 2011
Raid Level : raid0
Array Size : 71682176 (68.36 GiB 73.40 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Sep 22 14:37:24 2011
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : 7e018643:d6173e01:17ab5d05:f75b494e
Events : 0.9
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 65 1 active sync /dev/sde1
2 8 81 2 active sync /dev/sdf1
Кроме того, принудительное чтение из / dev / md0 подтверждает теорию о том, что / dev / sdf не удалось, но mdadm не помечает диск как сбойный:
# dd if=/dev/md0 of=/root/md.data bs=512 skip=255 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00367142 s, 139 kB/s
# dd if=/dev/md0 of=/root/md.data bs=512 skip=256 count=1
dd: reading `/dev/md0': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000359543 s, 0.0 kB/s
# dd if=/dev/md0 of=/root/md.data bs=512 skip=383 count=1
dd: reading `/dev/md0': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000422959 s, 0.0 kB/s
# dd if=/dev/md0 of=/root/md.data bs=512 skip=384 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000314845 s, 1.6 MB/s
Однако попытка доступа к диску / dev / sdf не выполняется:
# dd if=/dev/sdf of=/root/sdf.data bs=512 count=1
dd: opening `/dev/sdf': No such device or address
Данные для меня не так важны, я просто хочу понять, почему mdadm настаивает на том, чтобы массив был «State: clean»
В md (4) справочная страница проливает свет на то, как используется слово «чистый» (решающее значение выделено курсивом):
Нечистое отключение
При внесении изменений в массив RAID1, RAID4, RAID5, RAID6 или RAID10 существует вероятность несогласованности в течение коротких периодов времени, так как каждое обновление требует записи как минимум двух блоков на разные устройства, и эти записи, вероятно, не будут происходят в одно и то же время. Таким образом, если система с одним из этих массивов отключается в середине операции записи (например, из-за сбоя питания), массив может быть несовместимым.
Чтобы справиться с этой ситуацией, драйвер md помечает массив как "грязный" перед записью в него каких-либо данных и отмечает его как "чистый"при отключении массива, например, при выключении. Если драйвер md обнаруживает, что массив загрязнен при запуске, он приступает к исправлению любого возможного несоответствия. Для RAID1 это включает в себя копирование содержимого первого диска на все остальные диски. Для RAID4, RAID5 и RAID6 это включает в себя пересчет четности для каждой полосы и проверку того, что блок четности содержит правильные данные. Для RAID10 это включает в себя копирование одной из реплик каждого блока на все остальные. Этот процесс, известный как «повторная синхронизация» или «повторная синхронизация», выполняется в фоновом режиме. Массив все еще можно использовать, хотя, возможно, с меньшей производительностью.
Если массив RAID4, RAID5 или RAID6 вышел из строя (отсутствует хотя бы один диск, два для RAID6) при перезапуске после некорректного завершения работы, он не может пересчитать четность, и поэтому возможно, что данные могут быть необнаружимо повреждены. Драйвер 2.4 MD не предупреждает оператора об этом состоянии. Драйвер 2.6 md не сможет запустить массив в этом состоянии без ручного вмешательства, хотя это поведение может быть отменено параметром ядра.
Вероятно, что диск в RAID вышел из строя после RAID был нормально отключен системой (например, при выключении). Другими словами, отказ диска произошел, когда RAID-массив находился в согласованном синхронизированном состоянии. Затем RAID будет отмечен как «чистый», и, когда он будет включен в следующий раз и один из его дисков откажет, этот флаг останется.
Помимо очевидного - что только люди, которые не ценят свои данные, используют RAID-0 - mdadm не предупреждает вас ни о чем, если вы не запустите демон монитора: mdadm --monitor /dev/md0.
Вы можете явно проверить проблемное устройство, используя: mdadm -E /dev/sdf.
Конечно, обнаружение отказа массива RAID-0 бессмысленно: он утерян, восстановитесь из резервных копий.