Synology具有md驱动程序和mdadm工具集的自定义版本，可在内核的rdev-> flags结构中添加“ DriveError”标志。
实际影响-如果您很不幸导致阵列故障（第一个驱动器），再加上第二个驱动器上的错误-阵列将进入一种状态，即使从驱动器上读取数据，该阵列也无法修复/重建阵列精细。
在这一点上，从THIS数组的角度来看，我并不真正担心这个问题，因为我已经撤消了内容并打算进行重构，但更多的是希望将来有一个解决之道。 ，因为这是我第二次受到它的困扰，而且我知道我已经看到其他人在论坛上问类似的问题。
对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设备，运行力重新组装，从设备/ etc中删除/读取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设备脱机并从头开始创建阵列。
我发现自己处于类似情况。您成功解决了这个问题吗？
—
dvorak 2014年
是的，我能够按照上述步骤重建阵列。我确实通过清除并从R5更改为R6进行了跟踪-因为在这一点上，我对Synology的“将整个阵列存储”的行为感到非常不满，我想确保容忍多个驱动器“失败” ”。在我们的案例中，第二个出现“小故障”错误的驱动器通过了扩展的智能测试，甚至没有出现任何问题。
—
内森·诺林格2014年
感谢您的帮助。我不太有把握摆弄这一切，我不是团队专家。我现在面临相同的问题，但就我而言，我有一个磁盘RAID 1阵列（/ dev / md3），其中/ dev / sde3被标记为可怕的[E]。我认为我应该可以按照与您相同的步骤进行操作，但是由于那是阵列的单个磁盘，因此我不知道它会做什么;-)。无论如何mdadm --stop / dev / md3命令失败（设备或资源繁忙）。我想我会把Google再
—
待一会儿
如果您无法停止阵列，则听起来好像正在使用该阵列-即已将其挂载，或者正在对该设备运行其他任务。
—
内森·纳林格2015年
对我来说幸运的是，Synology帮助我解决了该问题。它们足够友好，可以为我提供运行的命令。我已经把我的情况下，别人跑博客的信息到这个问题：dsebastien.net/2015/05/19/...
—
dSebastien