这是关于ZFS和RAID-Z的一个有些理论上的问题。 我将使用一个三磁盘单奇偶校验arrays作为示例，但是问题可以扩展到任何数量的磁盘和任何奇偶校验。
假设我们在池中有磁盘A，B和C，并且它是干净的。
现在假设我们为了replace磁盘C而物理地添加磁盘D，并且磁盘C仍然正常工作，并且只是在预防性维护中被replace。 一些pipe理员可能只是推C和安装D，这是有点更多的组织，因为设备不需要改变ID – 但是这会使arrays暂时退化，因此对于这个例子，假设我们安装D，没有离线或删除C. Solaris文档指出我们可以用一个命令来replace一个磁盘，而不是首先使用它：
zpool replace pool CD 这应该导致重塑到D上。让我们说，重新同步沿着“光标”向下“进行”。 （我不知道内部实现中使用的实际术语。）
假设现在通过重新同步中途，磁盘A失败。 从理论上讲，这应该是可恢复的，因为光标B和D包含足够的奇偶性，并且在光标B和C之下包含足够的奇偶性。 但是，这是否实际上是可以回收的，这在ZFS的内部devise决策中是我没有意识到的（在某些情况下手册没有提到）。
如果ZFS继续向光标下面的C发送写入，那么我们没事。 但是，如果ZFS内部对待C，就好像它已经消失一样，只能从A和B之间的奇偶校验重新同步D，并且只能在光标下面写入A和B，然后我们要敬酒。
一些试验可以回答这个问题，但我希望也许有人在这里已经知道ZFS处理这种情况的方式。 提前感谢您的任何见解！
使用基于文件的池（FreeBSD 8.3上的v28使用文件备份的md设备）进行testing表明它应该可以工作。 在重启程序正在进行时，我能够使其中一个剩余的磁盘脱机。 理想情况下，它需要使用真实磁盘进行testing，并确实需要100％确定，但是ZFS非常乐意让我离线磁盘。
在离线md0之前，池仍然处于ONLINE状态，所以在我看来，ZFS只是将replace的磁盘镜像到新磁盘上，但仍然在整个过程中处理整个磁盘。
NAME STATE READ WRITE CKSUM test DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 8480467682579886773 OFFLINE 0 0 0 was /dev/md0 md1 ONLINE 0 0 0 replacing-2 ONLINE 0 0 0 md2 ONLINE 0 0 0 md3 ONLINE 0 0 0 (resilvering)
磁盘C仍然在RAIDZ中一直使用，直到从VDev中删除。 正如Matt所指出的那样，ZFS通过将replace磁盘replace为replace磁盘来replace磁盘，并重新replace磁盘。 RAIDZ VDev永远不会降级，并且永远不会重置（直到A失败，这完全与replace操作分开）。
我不确定这个问题。
在大多数情况下， 你不应该使用RAIDZ ， 而是镜像…如果你这样做，你应该这样做，一个备用。
如果其中一个正在读取的磁盘失败或不可用，则重新生成将失败。 与不可恢复的读取错误相同。 磁盘C会消失的那一点…