在GNU/Linux中，我们有许多检查文件系统的实用程序，用于验证磁盘上的数据完整性。例如程序“fsck”。然而，它有几个主要的缺点。首先，如果您打算修复数据错误，则必须将磁盘离线。这意味着要停机。您必须在fsck之前使用“umount”命令卸载磁盘。对于根分区，这意味着要从另一种介质进行引导，如CDROM或U盘。根据磁盘大小的不同，停机时间可能需要数小时。其次，文件系统(如ext3或ext4)对底层数据结构(如LVM或RAID)一无所知。一个磁盘上可能只有一个坏块，但另一个磁盘上可能有一个完好的块。不幸的是，Linux上的软RAID不知道哪一块个好的哪一块是坏的，从ext3或ext4的角度来看，如果从包含好的块的磁盘读取，它将获得正确的数据，而从包含坏块的磁盘读取就会得到已损坏的数据，而且没法控制从哪个磁盘读取数据，并修复损坏的数据。在标准的GNU/Linux文件系统上，这些错误被称为“静默数据错误”，而且您对这些错误束手无所。

对于Linux上的ZFS，检测和纠正静默数据错误是通过清理磁盘来完成的。这在技术上类似于ECC RAM，如果错误驻留在ECC DIMM中，您可以找到另一个包含好数据的寄存器，并使用它来修复坏寄存器。这是一种已经存在了一段时间的老技术，但令人惊讶的是，在标准的日志记录文件系统套件中没有这种技术。此外，就像您可以在实时运行的系统上擦除ECC RAM一样，有了ZFS，您就可以在没有停机的情况下，也能够清理磁盘。

当ZFS对您的池执行清理时，它会根据已知的校验来检查存储池中的每个块。默认情况下，使用适当的算法从上到下对每个块进行校验和。目前，这里使用的是“fletcher 4”算法, 它一种256位的算法，而且它的性能很好。这可以更改为使用SHA-256算法，尽管可能不建议这样做，因为计算SHA-256校验和比fletcher 4更昂贵。但是，由于SHA-256，损坏的数据块有1/2256或1/1077的机会散列到相同的SHA-256校验和。这是一个0.00000000000000000000000000000000000000000000000000000000000000000000000000001%的机会。作为参考，使用市场上最可靠的硬件，未修复的ECC内存错误将更频繁地发生在大约50个数量级上。因此，当清理数据时，如果校验匹配，则您有一正确的数据块，但是如果它不匹配，那么这数据块已经损坏。

存储池不是自动执行的。您需要手动完成此操作，强烈建议您定期执行此操作。scrubbing数据的建议频率取决于底层磁盘的质量。如果您有SAS或FC磁盘，则每月一次就足够了。如果你有消费级的SATA或SCSI，你应该每周做一次。您可以使用以下命令轻松安排擦除：

正如您所看到的，您可以在scrub执行过程中获得改操作的状态。进行清理可能会严重影响磁盘和需要它们的应用程序的性能。因此，如果出于任何原因需要停止清理，可以使用 scrub 的 -s 参数。但是，您最好还是应该让擦洗继续完成。

您应该在您的根用户的crontab中放置类似于以下内容的内容，它将在每周日凌晨02：00执行一次清理：

如果您的存储池正在使用某种冗余，那么在scrub时ZFS不仅会检测静默数据错误，而且如果其他磁盘上存在良好的数据，它还会纠正这些错误。这就是所谓的“自我修复”，如下图所示。在我的RAIDZ帖子中，我讨论了如何使用RAIDZ使用奇偶校验和重建算法自我修复数据。我要把它简化一点，只用一个双向镜。假设应用程序需要一些数据块，并且在这些块中，其中的某个块已损坏。ZFS如何知道数据已损坏？通过检查块的SHA-256校验和，如前所述。如果一个块上的校验和不匹配，它将在镜像中查看我的另一个磁盘，看看是否可以找到一个好的块。如果是，则将好块传递给应用程序，然后ZFS将修复镜像中的坏块，以便它还传递SHA-256校验和。因此，应用程序将始终获得良好的数据，并且您的池将始终处于良好、干净、一致的状态。

Resilvering Data 与将数据重建或重新同步到新磁盘到数组中的概念相同。然而，对于Linux软RAID、硬RAID控制器和其他RAID实现，并没有区分哪些块实际处于活动状态，哪些处于非活动状态。因此，重建需要从磁盘的开始处开始，直到到达磁盘的末尾才结束。因为ZFS知道RAID结构和文件系统元数据，所以我们可以聪明地重建数据。与其在没有存储活动块的空闲磁盘上浪费时间，我们可以只关注那些活动块。如果您的存储池只有部分空间被填满，这可以大大节省时间。如果池只填满了10%，则意味着仅在10%的硬盘空间工作。因此，对于ZFS，我们需要一个新的术语，而不是“重建”、“重新同步”或“重建”。在这种情况下，我们将重建数据的过程称为 resilvering。

不幸的是，磁盘会坏掉，需要更换。如果您的存储池中有冗余，并且可以承受一些故障，即使池将处于“降级”模式，您仍然可以向应用程序发送数据和从应用程序接收数据。如果您拥有在系统处于活动状态时支持热插拔的磁盘，您可以在不停机的情况下更换磁盘(你很幸运)。如果没有，您仍需要识别故障磁盘并将其更换。如果您的池中有许多磁盘，例如24个，这可能是一项繁琐的工作。然而，大多数GNU/Linux操作系统供应商，如Debian或Ubuntu，都提供了一个名为“hdparm”的实用程序，它允许您发现池中所有磁盘的序列号。您可以运行如下内容：

/dev/sde似乎是我的已损坏的磁盘。系统中所有其他磁盘都可以获取到序列号，唯独这个没有。因此，我可以在存储阵列中通过排除，找出未打印的序列号，它就是我的坏磁盘。在这种情况下，我找到了序列号“JP2940HD01VLMC”。我拉出磁盘，用一个新磁盘替换它，并查看是否重新填充了/dev/sde，其他磁盘仍然在线。如果是这样，我已经找到了我的磁盘，可以将其添加到池中。这实际上在我的两个个人管理程序上已经发生了两次。这个过程很快，不到10分钟硬盘就已经重新在线了。

要将池中的失效磁盘替换为新磁盘，可以使用“REPLACE”子命令。假设新磁盘也将自身标识为/dev/sde，那么我将发出以下命令：

resilver类似于使用软RAID进行重建。它会在新磁盘上重建数据块，直到镜像处于完全健康状态。查看resilver的状态可以让您了解改操作何时可以完成。

可以通过传递“-x”参数来快速确定一切是否正常运行，而不需要“zpool status”命令的完整输出。这对于无需复杂逻辑即可进行解析的脚本非常有用，因为如果出现故障，脚本可能会向您发出警报：

“zpool status”命令中的行为您提供了有关池的重要信息，其中大多数都是不言而喻的。它们的定义如下：

状态栏的“READ”、“WRITE”和“CHKSUM”列的定义如下：

定期scrub数据可确保存储池中的数据块保持一致。尽管擦除可能会给希望读取或写入数据的应用程序带来压力，但它可以在未来省去数小时的来修复错误。此外，由于您可能在任何时候都有“损坏的设备”(请参阅http://docs.oracle.com/cd/E19082-01/817-2271/gbbvf/index.html中有关使用ZFS损坏的设备的信息)，因此正确了解如何修复设备以及更换设备时会发生什么，这对存储管理至关重要。当然，关于这个主题我还有很多可以讨论的内容，但这至少应该向您介绍scrub和resilve的概念。