Synology имеет настроенную версию драйвера md и наборов инструментов mdadm, которая добавляет флаг DriveError в структуру rdev-> flags в ядре.
Чистый эффект - если вам не повезло получить сбой массива (первый диск) в сочетании с ошибкой на втором диске - массив переходит в состояние, не позволяющее вам восстановить / восстановить массив, даже если чтение с диска работает хорошо.
На данный момент меня не очень беспокоит этот вопрос с точки зрения ЭТОГО массива, поскольку я уже снял контент и собираюсь реконструировать, но больше из-за желания иметь путь разрешения для этого в будущем , так как это второй раз, когда меня это укусило, и я знаю, что видел, как другие задавали похожие вопросы на форумах.
Поддержка Synology была менее чем полезной (и в основном не реагирующей) и не будет делиться какой-либо информацией о работе с наборами рейдов на коробке.
Содержимое / proc / mdstat:
ds1512-ent> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]
md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
2097088 blocks [5/5] [UUUUU]
md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
2490176 blocks [5/5] [UUUUU]
unused devices: <none>
Статус из mdadm --detail / dev / md2:
/dev/md2:
Version : 1.2
Creation Time : Tue Aug 7 18:51:30 2012
Raid Level : raid5
Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
Raid Devices : 5
Total Devices : 5
Persistence : Superblock is persistent
Update Time : Fri Jan 17 20:48:12 2014
State : clean, degraded
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Name : MyStorage:2
UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
Events : 427234
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 21 1 active sync /dev/sdb5
2 8 37 2 active sync /dev/sdc5
3 8 53 3 active sync /dev/sdd5
4 8 69 4 active sync /dev/sde5
5 8 5 - spare /dev/sda5
Как видите - / dev / sda5 был повторно добавлен в массив. (Это был привод, который полностью вышел из строя) - но даже если md видит диск как запасной, он не будет восстанавливать его. / dev / sde5 в данном случае - это проблемный диск с состоянием (E) DiskError.
Я попытался остановить устройство MD, выполнить повторную сборку, удалить / прочитать sda5 с устройства и т. Д. Никаких изменений в поведении.
Мне удалось полностью воссоздать массив с помощью следующей команды:
mdadm --stop /dev/md2
mdadm --verbose \
--create /dev/md2 --chunk=64 --level=5 \
--raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5
который вернул массив в это состояние:
md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
Затем я повторно добавил / dev / sda5:
mdadm --manage /dev/md2 --add /dev/sda5
после чего началась перестройка:
md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
[>....................] recovery = 0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec
Обратите внимание на положение «отсутствующего» диска, которое точно соответствует положению отсутствующего слота.
Как только это закончится, я, вероятно, вытащу сомнительный диск и снова его восстановлю.
Я ищу любые предложения относительно того, есть ли какой-либо «менее страшный» способ выполнить это восстановление - или если кто-то прошел через этот опыт с массивом Synology и знает, как заставить его перестроиться, кроме отключения устройства MD и воссоздание массива с нуля.
Просто дополнение к решению, которое я нашел после того, как столкнулся с той же проблемой. Я последовал за dSebastienСообщение в блоге о том, как воссоздать массив:
Я обнаружил, что этот метод воссоздания массива работает лучше, чем этот метод выше. Однако после повторного создания массива том по-прежнему не отображался в веб-интерфейсе. Ни один из моих LUN не показывался. В основном показывает новый массив без ничего настроенного. Я связался со службой поддержки Synology, и они удалились, чтобы решить проблему. К сожалению, они удалились, пока я был вдали от консоли. Однако мне удалось запечатлеть сеанс, и я посмотрел, что они сделали. При попытке восстановить некоторые из моих данных диск снова сломался, и я снова оказался в той же ситуации. Я воссоздал массив, как в блоге dSebastien, а затем просмотрел сеанс синологии, чтобы выполнить их обновление. После выполнения приведенных ниже команд мой массив и LUN появились в веб-интерфейсе, и я смог работать с ними. У меня практически нулевой опыт работы с Linux, но именно эти команды я выполнял в своей ситуации. Надеюсь, это поможет кому-то другому, но, пожалуйста, используйте это на свой страх и риск. Лучше всего обратиться в службу поддержки Synology и попросить их исправить это за вас, так как эта ситуация может отличаться от вашей.
DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass
DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()
DiskStation> spacetool --synoblock-enum
****** Syno-Block of /dev/sda ******
//I've removed the output. This should display info about each disk in your array
DiskStation> vgchange -ay
# logical volume(s) in volume group "vg1" now active
DiskStation> dd if=/dev/vg1/syno_vg_reserved_area of=/root/reserved_area.img
24576+0 records in
24576+0 records out
DiskStation> synospace --map_file -d
Success to dump space info into '/etc/space,/tmp/space'
DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()
DiskStation> synocheckiscsitrg
synocheckiscsitrg: Not Pass, # conflict
DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass
Еще одно дополнение: я столкнулся с очень похожей проблемой с моим устройством с одним диском / RAID уровня 0.
Поддержка Synology была очень полезно и восстановил мое устройство. Вот что произошло, надеюсь, это поможет другим:
На моем диске были ошибки чтения в одном конкретном блоке, сообщения в системном журнале (dmesg) мы:
[4421039.097278] ata1.00: read unc at 105370360
[4421039.101579] lba 105370360 start 9437184 end 5860528064
[4421039.106917] sda3 auto_remap 0
[4421039.110097] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6
[4421039.116744] ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
[4421039.125410] ata1.00: failed command: READ FPDMA QUEUED
[4421039.130767] ata1.00: cmd 60/00:08:b8:d2:47/02:00:06:00:00/40 tag 1 ncq 262144 in
[4421039.130772] res 41/40:00:f8:d2:47/00:00:06:00:00/40 Emask 0x409 (media error) <F>
[4421039.146855] ata1.00: status: { DRDY ERR }
[4421039.151064] ata1.00: error: { UNC }
[4421039.154758] ata1: hard resetting link
[4421039.667234] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[4421039.887286] ata1.00: configured for UDMA/133
[4421039.891777] ata1: UNC RTF LBA Restored
[4421039.895745] ata1: EH complete
Через несколько секунд я получил ужасный Volume 1 has crashed почта с моего устройства.
- Отказ от ответственности: обязательно замените имя устройства своим, а не просто копируйте и вставляйте эти команды, так как это может ухудшить ситуацию! -
После остановки smb я смог повторно смонтировать раздел только для чтения и запустить e2fsk с проверкой badblocks (-c):
umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2
(можно также использовать e2fsck -C 0 -p -v -f -c /dev/md2 работать как можно без присмотра, хотя в моем случае это не сработало, потому что ошибки приходилось исправлять вручную. Поэтому мне пришлось перезапустить e2fsck. Вывод: -p не имеет особого смысла в случае ошибки диска)
Хотя e2fsck смог исправить ошибки, а smartctl также не показал увеличения Raw_Read_Error_Rate, том по-прежнему не мог монтироваться устройством в режиме чтения-записи. DSM по-прежнему показывал "сбой тома"
Итак, я открыл тикет с поддержкой. Сначала потребовалось много времени, чтобы все заработало, но в конце концов они исправили это, перестроив массив RAID с помощью:
synospace --stop-all-spaces
syno_poweroff_task -d
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3
Обязательно проверьте имена своих устройств (/dev/mdX и /dev/sdaX) прежде чем что-либо делать. cat /proc/mdstat покажет соответствующую информацию.