如何在驱动器处于“E”状态的情况下恢复Synology NAS上的mdadmarrays?

Synology有一个自定义版本的md驱动程序和mdadm工具集,在内核的rdev->标志结构中添加了一个“DriveError”标志。

净效应 – 如果你不幸得到arrays故障(第一个驱动器),再加上第二个驱动器上的错误 – arrays进入不让你修复/重buildarrays的状态,即使从驱动器读取工作精细。

在这一点上,从这个arrays的angular度来看,我并不是真的很担心这个问题,因为我已经把这个内容关掉了,打算重build,但是更多的是希望在未来有一个解决的途径,因为这是我第二次碰到它,而且我知道在论坛上我也见过其他人问过类似的问题。

Synology的支持一直不太有用(而且大部分是不响应的),并且在处理盒子上的raidset时不会共享任何信息。

/ 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看到驱动器作为备用,它不会重build。 在这种情况下,/ dev / sde5是(E)DiskError状态的问题。

我试图停止MD设备,运行强制重组,从设备/等删除/读取SDA5。 行为没有变化。

我能用下面的命令完全重新创build数组:

 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 

这使arrays回到这个状态:

 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 

之后开始重build:

 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 

请注意“丢失”驱动器的位置与缺less插槽的确切位置相匹配。

一旦完成,我想我可能会拉动可疑的驱动器,并重新进行重build。

我正在寻找任何build议,以确定是否有任何“不那么可怕”的方式来进行这种修复 – 或者如果有人已经通过Synologyarrays了解了这种体验,并知道如何强制重build,而不是让md设备脱机,从头重新创build数组。

只是在遇到同样的问题之后,我find了解决scheme的补充。 我跟着dSebastien的博客文章介绍了如何重新创build数组:

我发现重新创build数组的方法比上面的方法更好。 但重新创buildarrays后,卷仍然没有显示在Web界面上。 我的LUN都没有显示。 基本上显示一个没有configuration的新arrays。 我联系了Synology的支持,他们远程解决了这个问题。 不幸的是,他们在远离控制台的时候远程进入了远程。 我确实设法抓住会议,并通过了他们做了什么。 同时试图恢复我的一些数据,驱动器再次坠毁,我又回到了相同的情况。 我在dSebastien的博客中重新创build数组,然后查看Synology会话以执行更新。 在运行下面的命令之后,我的arrays和LUN出现在Web界面上,我可以和他们一起工作。 我在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