我有一个有8个磁盘的降级arrays。
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 REBUILDING 26% - 64K 1629.74 ON OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 232.88 GB 488397168 VDB41BT4DM3Z6C p1 OK u0 232.88 GB 488397168 VDB41BT4CMARDC p2 DEGRADED u0 232.88 GB 488397168 VDB41DT4EGWREC p3 OK u0 232.88 GB 488397168 VDB41BT4CHU1RC p4 OK u0 232.88 GB 488397168 VFA100R1CGR0LB p5 DEVICE-ERROR u0 232.88 GB 488397168 VDB41BT4CMJ5MC p6 OK u0 232.88 GB 488397168 VDB41BT4CMARYC p7 OK u0 232.88 GB 488397168 VDB41BT4CMJJHC 我在p2处更换了出现故障的磁盘，并且开始重build时没有任何问题，但重build时大约有16％， p5处的磁盘抛出DEVICE-ERROR ，暂停重build过程。
当我重新扫描（ tw_cli / c3 rescan ）时， DEVICE-ERROR消失，重新开始。 大约26％，这个DEVICE-ERROR再次出现，这次打破了从0％开始的重build过程。
这已经发生了一个星期了，我不能重buildarrays。 是否有任何方法可以忽略这个DEVICE-ERROR ，直到数组被重build？
是的，你做错了。 您更换发生故障的磁盘， 然后重新构buildarrays。 当然，现在不行。 你正试图重build数据到坏的磁盘上。 这不会工作。
我也build议RAID5（在今天这个时代），与8个磁盘是一个坏主意。
使用RAID6，或者至less有一个热备份。 这些磁盘并不是很大，所以你可能能够摆脱现在的设置，但是你也引入了一个不小的机会，即重build过程会导致另一个磁盘发生故障（并破坏数组）。
根据您的更新信息，您可能会错过修复此arrays的问题。
然而，在承认失败之前，在p5上扫描磁盘坏块或磁盘扇区可能是个好主意，以防DEVICE ERROR如此简单。 如果是，则修复错误，继续重build，然后更换磁盘p5并重新进行重build。
假设这还不够，那么现在最好的方法是从数组中复制数据（或从备份中恢复）。 如果您没有备份，那么某些数据将被破坏/丢失 – 至less，您在尝试访问P5时收到DEVICE-ERROR的数据，因此您可能必须手动排除这些文件）或复制过程中的目录。 （当然，这可能比这更糟糕，但无论如何，只要尽可能地做到最好）。
一旦数据安全，或者尽可能多地获取数据，就可以在将数据复制回来之前以更好的格式重新创buildarrays。 现在我个人不会使用RAID 1/10或6/60以外的任何东西，但这最终取决于您，但希望这教会了您有关RAID5的教训并不是一个好主意。