我们有一台带有3Ware 9650SE 8硬盘RAID控制器的Debian服务器，5个磁盘RAID6arrays，充当虚拟机主机，全部是Linux。 问题不断发生，我怀疑一个未被发现的破碎的磁盘。
现在，我们已经发生了几次崩溃事件，主机和所有客人都在说IO系统被阻塞了120秒或更长时间。 我们怀疑RAID控制器有问题，但我们用相同的固件取代了它，但是没有解决这个问题。 我不这么认为，因为第二个RAID1arrays保持正常工作。
差不多一个星期前（星期天），当这个行动起来的时候，汽车validation是66％。 昨天晚上（星期五早上）是67％。 在启动之前和之后，都遇到问题。 当我closuresvalidation与tw_cli /c0/u0 stop verify ，事情变得再次响应。
我怀疑它在66％左右的磁盘故障卡住了。 自动validation在星期六开始：
# tw_cli /c0 show verify /c0 basic verify weekly preferred start: Saturday, 12:00AM
而且通常会在星期五之前完成。 看到星期天是66％，星期五是67％，这不可能是巧合。
所有驱动器上的'smartctl -a -d 3ware，0 / dev / twa0'和'smartctl -t long'（长SMART自检）没有发现任何错误。 tw_cli /c0 show alarms也不tw_cli /c0 show alarms 。
我怀疑磁盘是以难以察觉的方式被破坏的，但是我将每个磁盘驱动器逐个从arrays中取出，创build了一个“单个”arrays，并且满了零。 没有磁盘显示错误。
还是有其他build议？
编辑：
这是布局：
# tw_cli /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-6 OK - - 256K 5587.9 RiW OFF u1 SPARE OK - - - 1863.01 - OFF u2 RAID-1 OK - - - 1862.63 RiW ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - ST32000542AS p1 OK u0 1.82 TB SATA 1 - ST32000542AS p2 OK u0 1.82 TB SATA 2 - ST32000542AS p3 OK u0 1.82 TB SATA 3 - ST32000542AS p4 OK u0 1.82 TB SATA 4 - ST32000542AS p5 OK u1 1.82 TB SATA 5 - WDC WD2002FYPS-02W3 p6 OK u2 1.82 TB SATA 6 - WDC WD2002FYPS-02W3 p7 OK u2 1.82 TB SATA 7 - WDC WD2002FYPS-02W3 Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 0 xx-xxx-xxxx
有问题的单位是u0。
EDIT2：
tw_cli / c0 show diag显示了一些有趣的东西（edit3：这是无害的，我发现它是由调用smartctl -a -d 3ware,X /dev/twa0 ，其中X是无效的端口）：
QueueAtaPassthrough() called with invalid TargetHandle: 0x17, portHandle: 0xFF Legacy opcode=0xB1 error=0x10E E=010E T=14:15:51 : Invalid operation for specified port E=010E T=14:15:51 U=0 : Return error status to host Error, Unit 23: Invalid operation for specified port (EC:0x10e, SK=0x05, ASC=0x24, ASCQ=0x00, SEV=01, Type=0x70) No additional sense data Error, Unit 23: 0x10E OVERRIDDEN due to invalid sense buffer descriptor sense buffer: len=0, address=0x414ca2c7c Send AEN (code, time): 0031h, 06/21/2013 14:26:16 Synchronize host/controller time (EC:0x31, SK=0x00, ASC=0x00, ASCQ=0x00, SEV=04, Type=0x71)
我得到了这些吨。 我不知道这是什么意思。 我什至不能确定它是哪个单位或港口。 （编辑3：我现在知道，这是无害的）。
鉴于我的编辑3，我回到了原点。 没有任何内容表示磁盘已损坏，除了validation挂起在66％，导致arrays挂起，有时也会随机发生。 我希望validation会发现错误…
只是为了确保你的固件版本是什么？
有一个我遇到的问题 – 这听起来很像你所描述的 – 满足以下要求： – 3ware 96xx系列控制器 – RAID 6 – 256k条带大小 – 固件版本<v4.10.00.021 *
当时没有可用的固件修复，所以我从256k到64k的条带大小迁移，这也解决了这个问题。 您可以尝试解决方法，但它肯定需要几天时间才能完成。
后来，我尝试了新的固件（* 4.10.00.021我认为有修复）与256k，像一个魅力工作。 4.10.00.027是最新版本。
此问题可能是由于其中一个磁盘遇到读取错误并阻止整个arrays，直到它设法重新分配该扇区，或者RAID控制器认为该驱动器已死并将其从arrays中引导出来，将其标记为“降级” （这完全取决于所讨论的控制器）。 如果磁盘开始死亡但是仍然通过SMART，可能会经常发生这种情况。 大多数消费者磁盘将继续尝试读取永远。
这个问题在一些驱动程序中被解决，这些驱动程序使用称为错误恢复控制的东西。 西部数据公司称这个TLER。 来自网站：
RAID-specific time-limited error recovery (TLER) - Pioneered by WD, this feature prevents drive fallout caused by the extended hard drive error-recovery processes common to desktop drives.
基本上，它告诉一个磁盘，如果它不能读扇区，在x秒后放弃。 这在RAID中是很好的，因为可以从另一个磁盘恢复数据。
从我读过的内容来看，ST32000542AS没有实现任何forms的ERC，因此它们中的任何一个都可以阻塞整个arrays。 WD2002FYPS实际上实现了WD的TLER，所以不会造成这个问题。