服务器 Gind.cn
  1. 服务器 Gind.cn
  3. zpool清除后错过的写入会发生什么？
Intereting Posts
将EC2server映像存储在存储桶“子文件夹”中 Debian挤压内核 vSphere Client中的客户端ESXi 4内存使用情况 多个RAIDarrays在x346 如何将postgres结果插入到shellvariables中 如何在FreeBSD 8上部署Rails 3？ 错误Tasklist.exe 调整/扩展分区大小CentOS 远程pipe理Windows机器 如何查看linux隐藏进程并删除rootkit 大规模硬盘擦除 公平带宽重新分配在多个用户之间 在RHEL 6.8中打开防火墙端口 Debian debian文件系统布局 2个双核心与1个四核心性能

zpool清除后错过的写入会发生什么？

我试图理解ZFS在特定条件下的行为，但是文档对此并不十分明确，所以我只是猜测。

假设我们有一个冗余的zpool。 采取以下一系列事件：

  1. 设备D和服务器之间的连接出现问题。 这会导致大量故障，因此ZFS会使设备出现故障，导致池处于降级状态。

  2. 当池处于降级状态时，池会发生变化（数据被写入和/或更改）。

  3. 连接问题在物理上被修复，使得设备D 再次可靠 。

  4. 由于知道D上的大多数数据是有效的，并且不想不必要地使用重复器来强调池，所以pipe理员运行zpool clear pool D Oracle的文档中指出这是由于已经纠正的暂时性问题导致故障的适当操作。

我读过zpool clear只清除错误计数器，并将设备恢复到联机状态。 但是，这有点麻烦，因为如果这样做，它会使游泳池处于不一致的状态！

这是因为步骤2中的突变不会被成功写入D.相反，D将在连接失败之前反映池的状态。 这当然不是zpool的规范性状态，并且可能导致其他设备发生故障时硬盘数据丢失 – 但是，池状态不会反映出这个问题！

我至less会假设基于ZFS强大的完整性机制，试图读取D中的变异数据会发现错误并修复它们。 但是，这提出了两个问题：

  1. 除非擦洗完成，否则读数不能保证能够达到所有的突变。 和

  2. 一旦ZFS 确实击中了突变的数据，它（我猜）可能会再次错误的驱动器，因为它似乎是ZFS是破坏数据，因为它不记得以前的写入失败。

从理论上讲，ZFS可以通过跟踪在降级状态期间发生的突变并在清除时将其写回到D来避开这个问题。 出于某种原因，我怀疑这不是什么情况。

我希望对ZFS有深入了解的人可以从这方面了解一些情况。

“从理论上说，ZFS可以通过跟踪在退化状态下发生的突变并在清除时将它们写回D来避开这个问题，但由于某种原因，我怀疑这并不是什么情况。

其实，这几乎就是在这种情况下可以做到的。 请参阅每次写入ZFS池中的磁盘时，将当前全局池事务标识写入磁盘。 所以说，例如，你有你解释的情况发生，并且连接丢失和恢复之间的总时间小于127 * txg_timeout（这是对池的负载和其他一些事情的大量假设，但是为了安全起见，只能说一半，所以如果txg_timeout是10秒，那么600秒或者10分钟是合理的时间。

在断开连接之前，池能够成功写入与事务ID 20192相关的写入。时间stream逝，磁盘又回来了。 当磁盘再次可用时，池已经有许多事务组通过，并且处于事务ID20209.在这一点上，ZFS仍然可以做所谓的“快速恢复”在那里它重塑磁盘，但只有交易ID的20193年到20209年，而不是一个完整的硬盘驱动器。 这样可以快速高效地将磁盘备份到池中的其余部分。

但是，启动该活动的方法不是“zpool clear”。 如果一切正常，应该在磁盘恢复健康的时候自动将其重新启动。 事实上，它可能是如此之快，你从来没有看到它。 在这种情况下，“zpool clear”将是清除当设备首先消失时将出现的仍然可见的错误计数的适当活动。 根据您使用的zfs版本，操作系统，zfs列出的设备以及在该状态下存储多长时间，解决此问题的“正确”方法会有所不同。 它实际上可以是“zpool clear”（清除错误，下一次访问驱动器应该注意到不同步的txg id，并在反弹器中启动），或者您可能需要使用'zpool online'或'zpool replace' 。

当所有这些工作正常时，我常常看到的是磁盘消失，驱动器进入脱机状态或降级，故障或UNAVAIL或REMOVED状态。 然后，当操作系统级别再次访问驱动器时，FMA和其他OS机制启动，ZFS知道磁盘已经返回，并且存在快速恢复程序，并且设备再次以ONLINEforms出现在zpool状态，但仍然可能有与它相关的错误计数。 关键是它处于联机状态，这将表明自动修复（重启）成功。 您可以在任何驱动器上testing它，方法是将其拉出，等待几秒钟，然后检查“zpool status”，然后重新插入磁盘并再次检查“zpool status”，看看会发生什么情况。 ZFS并不是这里唯一的移动部分 – ZFS实际上很大程度上依赖于其他操作系统机制来通知它磁盘的状态，如果这些机制失败，您将得到不同的症状，如果它们成功。

无论是哪种情况，快速恢复程序都可以运行并成功，否则不可能或失败。 如果是后者，磁盘将不得不在返回工作之前完成一个完全重启，所以通常不会出现在post底部列出的两个问题，除非pipe理员重写允许一个不匹配的txgid磁盘重新进入磁盘没有任何forms的纠正，这种差距（通常不应该是可能的）。 如果发生这种情况，我会怀疑下次访问驱动器会导致启动快速恢复（并成功或失败，并将磁盘敲到完全恢复），否则最终会将磁盘踢出 – – 或可能恐慌，由于txgid差距。 在任何这些事件中，不会发生数据丢失或将不正确的数据返回给请求。

注意：

  1. 每个数据块在ZFS上都有公平的校验和。 因此，ZFS知道哪个驱动器在故障时保留了冗余设置中的正确数据。 运行zpool scrub ZFSPOOL将修复数据或将数据传播到RADZ的所有正在运行的驱动器。
  2. ZFS采用Reed-Solomon的错误纠正 ，这是错误突发的最佳解决scheme。 丢失的驱动器是这样的突发错误，RS可以纠正。

我在驱动器上遇到了很多DMA错误，当数据中心和ZFS的空调问题能够解决这个问题的时候。 这只是简单的镜子。

我记得SUN在推出ZFS时发布的宣传video，他们在部署到8端口USB集线器的USB闪存驱动器上制作了RAIDZ，然后随机更换集线器中的less数位置，同时在该池上进行IO操作，观察无中断。