主页 / server / 问题 / 641318
Accepted
user
Asked: 2014-11-02 04:24:15 +0800 CST

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

  • 772

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

  1. 失败将记录在相关设备的 READ 或 CKSUM 统计信息中，并向上传播到池级别。
    • 冗余数据将用于重建请求的块，将请求的块返回给调用者，如果 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报告说 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 扇区，进而有望触发驱动器的重定位？

zfs

2 个回答

  1. Best Answer

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

    这意味着当 ZFS 文件系统驱动程序获得读取结果时，数据已经全部到位，并且正确，但发生的时间可能比正常情况要长一些。当然，没有高于平均延迟的错误计数器，所以没有记录。

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

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

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

    • 1

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

    这就是发生的事情...... ZFS 承诺零文件系统错误，而不是零数据错误。当遇到严重的损坏时，它会回滚事务，做任何必要的事情来使文件系统完整性良好。因此，当文件回滚到损坏之前文件的早期版本时，文件更新会丢失，因此可能会发生数据丢失。但是您的文件系统没有错误。

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

    • 0

相关问题