我有一个configuration了Perc H700卡的Xenserver主机上的RAID 50，几个星期前，更换了一个失败的磁盘。 RAID已经重build，我现在通过omreport检查数组的状态：
# omreport storage vdisk Controller PERC H700 Integrated (Slot 4) ID : 0 Status : Critical Name : Virtual Disk 0 State : Resynching Hot Spare Policy violated : Not Assigned Virtual Disk Bad Blocks : Yes Encrypted : Not Applicable Layout : RAID-50 Size : 14,900.00 GB (15998753177600 bytes) Associated Fluid Cache State : Not Applicable Device Name : /dev/sda Bus Protocol : SATA Media : HDD Read Policy : Adaptive Read Ahead Write Policy : Write Through Cache Policy : Not Applicable Stripe Element Size : 64 KB Disk Cache Policy : Enabled 我的问题是，为什么国家在Resynching这么长时间里陷入困境？ 没有太多的IO活动，因为目前没有虚拟机在主机上运行。 还有什么Resynching涉及？
另一点要提的是电池的状态是至关重要的：
# omreport storage battery Controller PERC H700 Integrated (Slot 4) ID : 0 Status : Critical Name : Battery 0 State : Failed Recharge Count : Not Applicable Max Recharge Count : Not Applicable Learn State : Idle Next Learn Time : 15 days 22 hours Maximum Learn Delay : 7 days 0 hours Learn Mode : Auto
但是使用Megacli，它将电池显示为Optimal：
BBU status for Adapter: 0 BatteryType: BBU Voltage: 4035 mV Current: 0 mA Temperature: 27 C Battery State: Optimal
两份报告中的冲突的原因是什么？
在此先感谢，请询问是否需要更多信息。
读取磁盘来计算“resync”数据的过程中可能会遇到一些坏块。 由于您使用的是RAID50，如果在重build的“半”（RAID5）中遇到来自任何驱动器的坏块，则会自动产生URE（由Dell称为“ 穿孔 ”）。
我说我怀疑这是因为你看到的Virtual Disk Bad Blocks : Yes – 坏块不会发生在虚拟磁盘级别，除非底层RAID由于多个部分坏或丢失而“丢失”一个块。 这就是生产数据在RAID10或RAID6上更安全的原因之一。 在几乎所有我遇到的虚拟级坏块中，唯一的解决方法是重新初始化RAID并从备份恢复。 唯一的逃避方法是，如果该块恰巧包含不需要读取的数据（或文件系统级别的空白空间），并最终被覆盖，否则可能会有某种程度的数据损坏应该被调查和处理。
至于电池状态的差异，我会相信omgaport超过omreport。 MegaCLI来自OEM（LSI），专门为此目的而devise，而omreport则负责监控所有戴尔硬件组件。 OMSA服务的重新启动或已安装版本的更新很可能会消除这种差异。
如果您对系统有主动保修，您可能还需要考虑联系戴尔，就这两方面提供build议。