![当池中有任何 raidz 设备时,为什么 ZFS vdev 删除不起作用?](https://linux22.com/image/788673/%E5%BD%93%E6%B1%A0%E4%B8%AD%E6%9C%89%E4%BB%BB%E4%BD%95%20raidz%20%E8%AE%BE%E5%A4%87%E6%97%B6%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%20ZFS%20vdev%20%E5%88%A0%E9%99%A4%E4%B8%8D%E8%B5%B7%E4%BD%9C%E7%94%A8%EF%BC%9F.png)
第一:我完全可以接受那目前情况就是这样,我并不寻求立即的解决方案,而是试图了解这个约束的技术限制。
我主要在 Linux 上使用 ZFS,但我的理解是,现在所有 FOSS ZFS 开发都植根于 OpenZFS,因此很感谢提供有关其任何/所有变体的信息。
这的手册页zfs remove
状态:
仅当主池存储不包含顶级 raidz vdev、所有顶级 vdev 具有相同的扇区大小且所有加密数据集的密钥都已加载时,才可以删除顶级 vdev。
我理解和/或可以猜测出大多数这些限制的原因,但我不太明白为什么仅仅在场raidz vdev 阻止删除任何(甚至是镜像或非冗余的)vdev。
我的理解/假设是,从池的角度来看,每个 vdev 都充当“哑块设备”,实际的冗余/镜像发生在 vdev 级别(正如反复警告所暗示的,池级别没有冗余:所有冗余必须存在于 vdev 级别,并且单个 vdev 出现故障会导致整个池瘫痪)。
在这个假设下,删除哪些特定的数据 vdev 并不重要,更不用说在场池中的“坏” (raidz) vdev。
显然,这个假设(或者我想不到的其他假设)是错误的。有人能告诉我是什么吗?
我唯一无法证实的猜测是,没有绝对raidz vdevs 会阻止 vdev 删除的原因,但是某些 raidz 特定操作和设备删除之间的某些交互目前尚未实现/测试/验证。
答案1
设备内部的数据RAIDZ
与单个或镜像 vdev 上的条带化方式不同。移除单个(或镜像)vdev 实际上意味着创建一个隐藏indirect
设备,其中包含一个将旧 DVA 地址重新映射(重定向)到新地址的表,但这需要元数据布局一样删除的设备与新设备之间的差异。当数据被复制到设备时,情况并非如此RAIDZ
。