为什么 ZFS 不对我的磁盘的 duff 扇区做任何事情？

Question

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

1. 故障将记录在相关设备的 READ 或 CKSUM 统计信息中，向上传播到池级别。
2. • 冗余数据将用于重建请求的块，将请求的块返回给调用者，如果 duff 驱动器仍然可用，则将块重写到它，或者
   • 如果冗余数据不可用于纠正读取错误，则将返回 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. 为什么ZFS不报告有关读取问题的任何信息？它显然正在从中恢复。

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

Answer 1

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

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

Reported_Un Correct 的 SMART 值不为 0 的事实使我怀疑故障原因是磁盘本身，而不是 SATA 电缆或 SATA 控制器不稳定。

如果是这种情况，那么即使块设备驱动程序尝试进​​行多次重试，磁盘最终也可能会更加严重并开始无法读取。因此我的建议是更换磁盘。

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