☰

为什么 ZFS 没有对我磁盘的坏扇区采取任何措施？

tag-icon • tag-icon zfs debian-wheezy zfsonlinux
为什么 ZFS 没有对我磁盘的坏扇区采取任何措施？

我的印象是，如果从 ZFS 池读取期间发生 I/O 错误，则会发生两件事：

  1. 故障将记录在相关设备的 READ 或 CKSUM 统计数据中，并向上传播至池级别。
    • 冗余数据将用于重建所请求的块，将所请求的块返回给调用者，并且如果坏驱动器仍然正常工作，则将该块重写到该驱动器中，或者
    • 如果没有冗余数据来纠正读取错误，则会返回 I/O 错误。

看来我的镜像设置中的一个磁盘出现了坏扇区。这本身并不令人担忧；这样的事情时有发生，这正是我设置冗余的原因（确切地说是双向镜像）。每次我清理池或读取特定目录中的文件时（我还没有费心确定哪个文件有问题），dmesg 中都会弹出以下内容，显然带有不同的时间戳：

Nov  1 09:54:26 yeono kernel: [302621.236549] ata6.00: exception Emask 0x0 SAct 0x9c10 SErr 0x0 action 0x0
Nov  1 09:54:26 yeono kernel: [302621.236557] ata6.00: irq_stat 0x40000008
Nov  1 09:54:26 yeono kernel: [302621.236566] ata6.00: failed command: READ FPDMA QUEUED
Nov  1 09:54:26 yeono kernel: [302621.236578] ata6.00: cmd 60/a8:78:18:5a:12/00:00:5c:01:00/40 tag 15 ncq 86016 in
Nov  1 09:54:26 yeono kernel: [302621.236580]          res 41/40:a8:18:5a:12/00:00:5c:01:00/00 Emask 0x409 (media error) <F>
Nov  1 09:54:26 yeono kernel: [302621.236585] ata6.00: status: { DRDY ERR }
Nov  1 09:54:26 yeono kernel: [302621.236589] ata6.00: error: { UNC }
Nov  1 09:54:26 yeono kernel: [302621.238214] ata6.00: configured for UDMA/133

这是相当最新的 Debian Wheezy，内核 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 x86_64，ZoL 0.6.3。软件包版本当前为 debian-zfs=7~wheezy、libzfs2=0.6.3-1~wheezy、zfs-dkms=0.6.3-1~wheezy、zfs-initramfs=0.6.3-1~wheezy、zfsutils=0.6.3-1~wheezy、zfsonlinux=3~wheezy、linux-image-amd64=3.2+46、linux-image-3.2.0-4-amd64=3.2.63-2。我所知道的唯一软件包固定是针对 ZoL 的，我有（由 zfsonlinux 软件包提供）：

Package: *
Pin: release o=archive.zfsonlinux.org
Pin-Priority: 1001

在驱动器上运行hdparm -R报告显示写入-读取-验证已打开（这是 Seagate，因此具有该功能，我将其用作额外的安全网；额外的写入延迟不是问题，因为我的交互式使用模式读取量很大）：

/dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX:
 write-read-verify =  2

即使有明显的迹象表明有问题，但zpool status仍声称游泳池没有问题：

  pool: akita
 state: ONLINE
  scan: scrub repaired 0 in 8h16m with 0 errors on Sat Nov  1 10:46:03 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        akita                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c50065e8414a  ONLINE       0     0     0
            wwn-0x5000c500645b0fec  ONLINE       0     0     0

errors: No known data errors

过去几天（自 10 月 27 日起）这个错误经常出现在日志中，所以我不太倾向于将其视为偶然事件。我以相当短的 SCTERC 超时运行磁盘；读取 1.5 秒（以便从读取错误中快速恢复），写入 10 秒。我已确认这些值在有问题的驱动器上有效。

smartd 不断骚扰我 (这本身是件好事！)，告知我 ATA 错误数量正在攀升：

The following warning/error was logged by the smartd daemon:

Device: /dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX [SAT], ATA error count increased from 4 to 5

For details see host's SYSLOG.

在有问题的驱动器上运行smartctl --attributes会产生以下结果：

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   076   063   044    Pre-fail  Always       -       48910012
  3 Spin_Up_Time            0x0003   091   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       97
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   030    Pre-fail  Always       -       1698336160
  9 Power_On_Hours          0x0032   089   089   000    Old_age   Always       -       9887
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       98
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   095   095   000    Old_age   Always       -       5
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       10
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   058   052   045    Old_age   Always       -       42 (Min/Max 20/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       61
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       492
194 Temperature_Celsius     0x0022   042   048   000    Old_age   Always       -       42 (0 11 0 0)
195 Hardware_ECC_Recovered  0x001a   052   008   000    Old_age   Always       -       48910012
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

没有什么明显地与众不同。请注意，这是企业级硬盘，因此保修期为五年和额定运行时间为 24x7（这意味着它可以可靠运行超过 40,000 小时，而迄今为止的运行时间还不到 10,000 小时）。请注意属性 187 Reported_Uncorrect 中的数字 5；这就是问题所在。还请注意 Start_Stop_Count 和 Power_Cycle_Count 值相当低，均低于 100。

我认为在这种情况下这并不相关，但是系统确实有 ECC RAM。

根的非默认属性文件系统池上有：

NAME   PROPERTY              VALUE                  SOURCE
akita  type                  filesystem             -
akita  creation              Thu Sep 12 18:03 2013  -
akita  used                  3,14T                  -
akita  available             434G                   -
akita  referenced            136K                   -
akita  compressratio         1.04x                  -
akita  mounted               no                     -
akita  mountpoint            none                   local
akita  version               5                      -
akita  utf8only              off                    -
akita  normalization         none                   -
akita  casesensitivity       sensitive              -
akita  usedbysnapshots       0                      -
akita  usedbydataset         136K                   -
akita  usedbychildren        3,14T                  -
akita  usedbyrefreservation  0                      -
akita  sync                  standard               local
akita  refcompressratio      1.00x                  -
akita  written               0                      -
akita  logicalused           2,32T                  -
akita  logicalreferenced     15K                    -

相应地泳池本身：

NAME   PROPERTY               VALUE                  SOURCE
akita  size                   3,62T                  -
akita  capacity               62%                    -
akita  health                 ONLINE                 -
akita  dedupratio             1.00x                  -
akita  free                   1,36T                  -
akita  allocated              2,27T                  -
akita  readonly               off                    -
akita  ashift                 12                     local
akita  expandsize             0                      -
akita  feature@async_destroy  enabled                local
akita  feature@empty_bpobj    active                 local
akita  feature@lz4_compress   active                 local

这些列表是通过运行获得的{zfs,zpool} get all akita | grep -v default。

现在问题是：

  1. 为什么不虚拟文件系统报告有关读取问题的任何信息？它显然正在恢复。

  2. 为什么 ZFS 不自动重写驱动器显然无法读取的坏扇区，进而希望触发驱动器的重定位，因为在读取请求路径中存在足够的冗余来自动修复？

答案1

我怀疑 ATA 驱动程序在收到错误时会重试读取操作几次，然后再将错误传回文件系统驱动程序。

这意味着当 ZFS 文件系统驱动程序获得读取结果时，数据已经全部存在且正确，但可能需要比正常情况下更长的时间。当然，对于高于平均水平的延迟，没有错误计数器，因此不会记录任何内容。

事实上，Reported_Uncorrect 的 SMART 值不为 0，这让我怀疑故障的原因是磁盘本身，而不是 SATA 电缆或 SATA 控制器出现问题。

如果是这种情况，磁盘最终很可能会进一步损坏，并且无论块设备驱动程序尝试多少次重试，磁盘仍会开始无法读取。因此，我的建议是更换磁盘。

触发长时间的 SMART 测试可能会在受影响的块上失败，如果您想让错误消失，重写这些块（例如使用 dd）应该会导致磁盘换出这些扇区，但根据我的经验，一旦驱动器开始运行，最好只是更换它并完成它。

答案2

我在 Solaris 上的 ZFS RAID 中发现了一个坏的 SCSI 磁盘。我扫描了日志文件以获取有关错误消息的信息，以收集磁盘坏的证据并让 Oracle 在硬件维护中弥补这一缺陷。我运行 grep 查找错误日志中的某些字符串，这些显示磁盘错误的行会出现在我的控制台屏幕上。当运行“Explorer”（Solaris 的系统日志和报告工具）并将其发送给 Oracle 时，他们说磁盘上没有错误。但我的屏幕历史记录中有这些错误。我检查了一下，发现它确实从磁盘日志中消失了。

事情是这样的……ZFS 承诺零文件系统错误，而不是零数据错误。当遇到严重损坏时，它会回滚事务，采取一切必要措施来确保文件系统的完整性。因此，当回滚到损坏之前的文件的早期版本时，文件更新会丢失，因此可能会发生数据丢失。但您的文件系统没有错误。

对于简单的错误，ZFS 可能可以回滚并再次重写数据，但在磁盘行为严重不良的情况下，它似乎会陷入无法恢复和写入数据的困境。如果您需要收集有关磁盘错误的证据，请将它们显示在屏幕上，而不要依赖于驻留在磁盘上的证据，因为 ZFS 事务回滚可能会重置磁盘上的数据。

相关内容