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

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

1. 该故障将记录在相关设备的READ或CKSUM统计信息中，并向上向池级别传播。
2. • 冗余数据将用于重建所请求的块，所请求的块返回给调用者，并且如果达夫驱动器仍然是官能重写块到它，OR
   • 如果没有可用的冗余数据来纠正读取错误，将返回一个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在驱动器上运行时，报告已启用Write-Read-Verify（这是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扇区，进而希望触发驱动器的重定位？

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

这意味着到ZFS文件系统驱动程序获得读取结果的时间时，数据就全部存在并且可以纠正，但是可能比正常情况花费了更长的时间。当然，没有比平均延迟高的错误计数器，因此没有任何记录。

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

如果是这种情况，即使在重试块设备驱动程序尝试多次之后，磁盘很可能最终将更多地死掉并开始读取失败。因此，我的建议是更换磁盘。

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

我的Solaris SCSI磁盘损坏，而SCSI磁盘损坏。我正在扫描日志文件以获取有关错误消息的信息，以收集磁盘是否损坏的证据，并让Oracle在硬件维护方面进行介绍。我在错误日志中为某些字符串运行了grep，这些行显示磁盘错误将在控制台屏幕中。当运行“ Explorer”（Solaris的系统日志和报告工具）并将其发送给Oracle时，他们说磁盘上没有错误。但是我在屏幕历史记录中显示了它们。我检查了一下，确实从磁盘上的日志中删除了它。

这就是正在发生的事情... ZFS保证文件系统错误为零，而不是数据错误为零。遇到严重损坏时，它将回滚事务，并执行使文件系统完整性良好的任何所需操作。如此一来，文件更新在损坏之前回滚到文件的较早版本时将丢失，因此可能会发生数据丢失。但是您的文件系统没有错误。

也许是由于简单的错误，ZFS可以回滚并在另一次尝试中重写数据，但是在磁盘行为不佳的严重情况下，它可能进入到catch-22的状态，无法恢复和写入数据。如果您需要收集有关磁盘错误的证据，请使它们出现在屏幕上，而不依赖于驻留在磁盘上的证据，在磁盘上，ZFS事务回滚可能会重置数据。