我的印象是，如果在从ZFS池读取过程中发生I / O错误，会发生两件事情：
看来我的镜像设置中的一个磁盘已经发展成一个坏扇区。 这本身并不令人担忧。 这样的事情发生了，这就是为什么我有冗余（准确地说是一个双向镜像）。 每次擦洗池或读取特定目录中的文件（我还没有仔细确定哪个文件出错），dmesg中显然会popup以下显示，具有不同的时间戳：
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，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，所以有这个function，我把它作为一个额外的安全networking;额外的写延迟不是一个问题，因为我的交互式使用模式非常重读）：
/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秒。 我已经确认这些值在驱动器上是有效的。
Amy的错误数量正在攀升：smartd一直在纠缠着我（这本身就是件好事！）
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
那里没有什么明显的。 请注意，这是一个企业驱动器，所以五年保修和 24小时全天候运行（这意味着它是可靠的超过40000小时的操作，相比之下，只有不到10000小时）。 注意属性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 {zfs,zpool} get all akita | grep -v default 。
现在提问：
为什么ZFS不能报告读取的问题？ 它显然正在从中恢复。
为什么ZFS不会自动重写duff扇区，驱动器显然是读取有问题，反过来希望通过驱动器触发重新定位，因为在读取请求path中有足够的冗余来进行自动修复？
我怀疑ATA驱动程序在将错误传递回文件系统驱动程序之前接收到错误时会重试读取操作几次。
这意味着当ZFS文件系统驱动程序获得读取结果的时候，数据就在那里，并且是正确的，但是可能需要比正常时间长一点的时间。 当然，没有错误计数器的延迟高于平均水平，所以没有logging。
Reported_Uncorrect的SMART值不为0这一事实使我怀疑故障的原因是磁盘本身，而不是说SATA电缆或SATA控制器有问题。
如果是这种情况，最有可能磁盘将最终死亡更多，并开始无法读取，即使无论块设备驱动程序尝试多次重试。 因此，我的build议是更换磁盘。
如果想让错误消失，重新写入这些块（例如使用dd）应该会导致磁盘换出这些扇区，但是根据我的经验，一旦驱动器启动后，触发长SMARTtesting可能会在受影响的块上失败去取代它并用它来做就更好了。
我在Solaris上安装了一个ZFS raid的SCSI磁盘。 我正在扫描日志文件以获取有关错误消息的信息，以收集磁盘坏的证据，并让Oracle在硬件维护上覆盖它。 我运行错误日志中的某些string的grep，显示磁盘错误的这些行将在我的控制台屏幕上。 当“资源pipe理器”（Solaris的系统日志和报告工具）运行并发送到Oracle时，他们表示磁盘上没有错误。 但是，我把它们放在了我的屏幕上。 我检查，它确实从磁盘上的日志不见了。
这是发生了什么… ZFS承诺零文件系统错误，而不是零数据错误。 当遇到严重的损坏时，它会回滚事务，按照要求使文件系统完好无损。 因此，文件更新在损坏之前回滚到文件的早期版本时会丢失，因此可能会发生数据丢失。 但是你的文件系统是没有错误的。
也许对于简单的错误，ZFS可以在另一次尝试中回滚和重写数据，但是在严重的磁盘行为的情况下，它可能进入catch-22，数据没有被恢复和写入。 如果您需要收集有关磁盘错误的证据，请使其出现在屏幕上，而不要依赖驻留在磁盘上的证据，而数据可能由ZFS事务回滚重置。