ZFS管理手册：第六章scrub和Resilver

标准验证

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

ZFS Scrubbing

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

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

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

# zpool scrub tank
# zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub in progress since Sat Dec  8 08:06:36 2012
    32.0M scanned out of 48.5M at 16.0M/s, 0h0m to go
    0 repaired, 65.99% done
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            sdg     ONLINE       0     0     0
            sdh     ONLINE       0     0     0
          mirror-2  ONLINE       0     0     0
            sdi     ONLINE       0     0     0
            sdj     ONLINE       0     0     0

errors: No known data errors

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

# zpool scrub -s tank

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

0 2 * * 0 /sbin/zpool scrub tank

自愈数据

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

Resilvering Data

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

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

# for i in a b c d e f g; do echo -n "/dev/sd$i: "; hdparm -I /dev/sd$i | awk '/Serial Number/ {print $3}'; done
/dev/sda: OCZ-9724MG8BII8G3255
/dev/sdb: OCZ-69ZO5475MT43KNTU
/dev/sdc: WD-WCAPD3307153
/dev/sdd: JP2940HD0K9RJC
/dev/sde: /dev/sde: No such file or directory
/dev/sdf: JP2940HD0SB8RC
/dev/sdg: S1D1C3WR

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

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

# zpool replace tank sde sde
# zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress for 0h2m, 16.43% done, 0h13m to go
config:

        NAME          STATE       READ WRITE CKSUM
        tank          DEGRADED       0     0     0
          mirror-0    DEGRADED       0     0     0
            replacing DEGRADED       0     0     0
            sde       ONLINE         0     0     0
            sdf       ONLINE         0     0     0
          mirror-1    ONLINE         0     0     0
            sdg       ONLINE         0     0     0
            sdh       ONLINE         0     0     0
          mirror-2    ONLINE         0     0     0
            sdi       ONLINE         0     0     0
            sdj       ONLINE         0     0     0

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

确定池问题

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

# zpool status -x
all pools are healthy

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

• pool : 池的名字
• state : 池目前的健康状况。该信息仅说明池是否有进行池复制的能力。
• status : 对池存在问题的描述。如果没有发现问题，则不会显示该字段。
• action : 修复错误的建议操作。如果没有发现问题，则不会显示该字段。
• see : 对包含详细修复信息的知识文章的引用。在线文章的更新频率超过本指南的更新频率，应参考这些文档以了解最新的修复过程。如果没有发现问题，则不会显示该字段。
• scrub : 标识 scrub 操作的当前状态，其中可能包括上次scrub完成、正在进行的scrub的日期和时间，或不需要执行scrub操作。
• errors : 识别已知数据错误或未知数据错误。
• config ： 描述池的设备和配置情况，以及设备的状态和错误信息。状态可以是以下状态之一：ONLINE, FAULTED, DEGRADED, UNAVAILABLE, 或者 OFFLINE。如果状态根本不是在线，那么池的容错能力就已经受到了影响。

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

• NAME : 池中每个VDEV的名称，以嵌套顺序显示。
• STATE : 池中每个VDEV的状态。该状态可以是上述“config”字段中的任何状态。
• READ : 发出读请求时发生I/O错误。
• WRITE : 发出写请求时发生I/O错误。
• CHKSUM : 检验错误。在处理读请求时，会返回错误的数据。

结论

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