ZFS无止境的重复

我在Debian上有一个大的（> 100TB）ZFS（FUSE）池，丢失了两个驱动器。当驱动器出现故障时，我用备件replace它们，直到我可以安排停机并在物理上replace坏的磁盘。

当我将系统closures并更换驱动器时，池会按预期启动重新同步，但当完成约80％（通常需要约100小时）时，重新启动。

我不确定一次更换两个驱动器是否会造成竞争状态，或者由于池的大小，重启器需要很长时间以致其他系统进程正在中断它并使其重新启动，但是没有明显的指示“zpool status”的结果或指向问题的系统日志。

我已经修改了我如何布置这些池以改善重新同步性能，但任何有关将此系统重新投入生产的线索或build议都是值得赞赏的。

zpool状态输出（自上次检查以来，错误是新的）：

pool: pod state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: resilver in progress for 85h47m, 62.41% done, 51h40m to go config: NAME STATE READ WRITE CKSUM pod ONLINE 0 0 2.79K raidz1-0 ONLINE 0 0 5.59K disk/by-id/wwn-0x5000c5003f216f9a ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CWPK ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQAM ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPVD ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ2Y ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CVA3 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQHC ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPWW ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09X3Z ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ87 ONLINE 0 0 0 spare-10 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F20T1K ONLINE 0 0 0 1.45T resilvered disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09BJN ONLINE 0 0 0 1.45T resilvered disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQG7 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQKM ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQEH ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09C7Y ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CWRF ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ7Y ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0C7LN ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQAD ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CBRC ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPZM ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPT9 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ0M ONLINE 0 0 0 spare-23 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F226B4 ONLINE 0 0 0 1.45T resilvered disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CCMV ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0D6NL ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CWA1 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CVL6 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0D6TT ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPVX ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09BGJ ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0C9YA ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09B50 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0AZ20 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BKJW ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F095Y2 ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F08YLD ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQGQ ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0B2YJ ONLINE 0 0 39 512 resilvered disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQBY ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0C9WZ ONLINE 0 0 0 67.3M resilvered disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQGE ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ5C ONLINE 0 0 0 disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CWWH ONLINE 0 0 0 spares disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CCMV INUSE currently in use disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09BJN INUSE currently in use errors: 572 data errors, use '-v' for a list

恭喜你，呃。你偶然发现了ZFS的一个更好的东西，但也犯了一个configuration罪。

首先，由于您使用的是raidz1，因此您只有一个磁盘值奇偶校验数据。但是，你有两个驱动器同时失败。唯一可能的结果是数据丢失 。没有重复的数量是要解决这个问题。

你的备件在这里帮了你一把，并且让你免于一场彻底的灾难性的失败。在这里，我要一瘸一拐地说，出现故障的两个驱动器不会同时发生故障，而在第二个驱动器出现故障前，第一个备用驱动器只能部分重新启动。

这似乎很难遵循。这是一张图片：

事件顺序

这实际上是一件好事，因为如果这是一个传统RAIDarrays，只要第二个驱动器出现故障，您的整个arrays就会立即脱机，您将无法进行就地恢复。但是因为这是ZFS，所以它仍然可以使用它所具有的部分来运行，并且仅仅返回块或文件级别的错误。

下面是你如何解决它：短期，从zpool status -v获取损坏的文件的列表，并将这些文件从备份复制到其原始位置。或删除文件。这将使恢复程序恢复并完成。

这是你的configuration罪孽：你在RAID组中有太多驱动器。

长期来看：您需要重新configuration驱动器。更合适的configuration是将驱动器安排在raidz1中的5个驱动器的小组中。 ZFS将自动跨越这些小组。这显着降低了驱动器出现故障时的重启时间，因为只有5个驱动器需要参与，而不是全部参与。这样做的命令是这样的：

 zpool create tank raidz da0 da1 da2 da3 da4 \ raidz da5 da6 da7 da8 da9 \ raidz da10 da11 da12 da13 da14 \ spare da15 spare da16