因此，ZFS正在报告一些“读取问题”，所以看起来这个磁盘是失败的，因为我们知道ZFS-8000-9P文档中没有提供任何报告。 这些磁盘是相当新的，我们最近唯一的问题是一个完整的ZFS。
ZFS在LSI MegaRAID 9271-8i上运行，所有磁盘每个磁盘运行“raid 0”。 我不是很熟悉这个RAID卡，所以我find一个脚本，返回从megacli命令行工具派生的数据。 我添加了1个驱动器来显示设置，它们都设置相同。 （系统盘不同）
zpool状态输出
pool: data state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://zfsonlinux.org/msg/ZFS-8000-9P scan: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 br0c2 ONLINE 0 0 0 br1c2 ONLINE 0 0 0 br2c2 ONLINE 0 0 0 br0c3 ONLINE 0 0 0 br1c3 ONLINE 0 0 0 br2c3 ONLINE 0 0 0 r2c1 ONLINE 0 0 0 r1c2 ONLINE 0 0 0 r5c3 ONLINE 0 0 0 sdb ONLINE 0 0 0 sdc ONLINE 0 0 0 sdd ONLINE 0 0 0 sde ONLINE 0 0 0 sdf ONLINE 0 0 0 sdg ONLINE 0 0 0 r3c1 ONLINE 0 0 0 r4c1 ONLINE 2 0 0 ... cut raidz2-1 ... errors: No known data errors LSI脚本的输出
Virtual Drive: 32 (Target Id: 32) Name : RAID Level : Primary-0, Secondary-0, RAID Level Qualifier-0 Size : 3.637 TB Sector Size : 512 Is VD emulated : No Parity Size : 0 State : Optimal Strip Size : 512 KB Number Of Drives : 1 Span Depth : 1 Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU Default Access Policy: Read/Write Current Access Policy: Read/Write Disk Cache Policy : Disk's Default Encryption Type : None PI type: No PI Is VD Cached: No
该脚本不会报告任何有故障的磁盘，raidcontroller也不会将该驱动器标记为有故障。 我发现一些其他的主题zpool错误 ，给了build议清除错误，并运行擦洗。 现在我的问题是，什么时候运行擦洗的阈值，需要多长时间（假设这个zfs raid会对运行擦洗性能造成影响）。另外，当这个磁盘真的很短暂时，热交换会初始化一个“重build” ？ 所有磁盘都是“西数4TB，SAS II，32MB，7200rpm，企业24/7/365”。 是否有一个系统，将检查zfs错误，因为这只是一个例行的手动检查？
zfs版本：0.6.4.1 zfsonlinux
我知道2读错误不是分配，但我宁愿要更换磁盘到早到晚。
zfs scrub是“将检查zfs错误的系统”。 只要读取存储在卷中的所有数据（按照txg的顺序进行，所以它可能需要很多的操作，具体取决于数据块有多完整以及数据是如何写入的）。 一旦开始， zfs status将显示一些估计。 运行擦洗可以停止。
如果您想要定期检查zpool status ，最简单的方法是运行zpool status | grep -C 100 Status zpool status | grep -C 100 Status定期（一次6小时），并发送电子邮件的输出（如果有的话）。 你也许可以find一个你最喜欢的监控系统的插件，如nagios。 或者写下自己会很简单。
只需热交换驱动器将不会触发反弹。 你将不得不运行zfs replace 。
你看到的读取错误可能是某种控制器的事故。 即使这是一个企业硬件，这些（HW RAID）控制器有时performance怪异。 例如，这些错误可能是一个命令耗时过长的结果 – 控制器忙于任何事情。 这就是为什么我试图远离这些，除非必要。
我会去检查驱动器上的SMART数据（请参阅man smartctl ）并擦洗池。 如果两者都看起来不错，清除错误，不要乱用你的游泳池。 因为如果池接近完全读取，则在重新启动期间的所有数据实际上可能会触发另一个错误。 一旦你再次看到同一个驱动器上的错误，开始panicing;）。
顺便说一句。 为获得最佳性能，您应该在RAIDZ2 vdevs中使用n ^ 2 + 2个驱动器。
我会做什么ZFS告诉你在这种情况下做。 请运行擦洗。
我每周按计划擦洗系统。 我还使用zfswatcher守护程序来监视Linux ZFS安装的运行状况。
你的ZFS数组可能未被修改，所以有一些值可以帮助提高清理性能，但是在这一点上，你应该运行它。
而对于另一个问题，你的热插拔可能不会做你期望的…看到下面的咆哮。
咆哮：
在硬件控制器后面有一堆RAID-0虚拟驱动器是一个坏主意！
你有两个世界上最糟糕的。 可恢复性和错误检查是有限的。 发生故障的磁盘本质上是一个失败的虚拟驱动器，并有热插拔的含义。 假设您删除有问题的磁盘。 您可能需要创build一个新的虚拟磁盘，或者可能会以不同的驱动器枚举结束。
在某个时候，最好是获得一个真正的HBA，然后运行磁盘作为尝试直通设备（没有RAID元数据），或者在硬件arrays保护的vdevs之上运行ZFS。 例如，在您的控制器上运行RAID-6并在顶部安装ZFS。 或者运行多个RAID-X组，并使用ZFS镜像或分条生成的vdevs。