為什麼 ZFS 沒有對我的磁碟的 duff 扇區做任何事情？
我的印像是，如果在從 ZFS 池讀取期間發生 I/O 錯誤，則會發生兩件事：
- 失敗將記錄在相關設備的 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。現在的問題：
- 為什麼ZFS不報告有關讀取問題的任何資訊？它顯然正在從中恢復。
- 鑑於在讀取請求路徑中存在足夠的冗餘用於自動修復，為什麼 ZFS 不會自動重寫驅動器顯然無法讀取的 duff 扇區，進而有望觸發驅動器的重定位？
我懷疑 ATA 驅動程序在將錯誤傳遞回文件系統驅動程序之前收到錯誤時會重試幾次讀取操作。
這意味著當 ZFS 文件系統驅動程序獲得讀取結果時，數據已經全部到位，並且正確，但發生的時間可能比正常情況要長一些。當然，沒有高於平均延遲的錯誤計數器，所以沒有記錄。
Reported_Uncorrect 的 SMART 值不為 0 的事實讓我懷疑故障的原因是磁碟本身，而不是說 SATA 電纜或 SATA 控制器不穩定。
如果是這種情況，很可能磁碟最終會死得更多，並且即使在塊設備驅動程序嘗試多次重試之後也開始無法讀取。因此，我的建議是更換磁碟。
觸髮長時間的 SMART 測試可能會在受影響的塊上失敗，如果您想讓錯誤消失，重寫這些塊（例如使用 dd）應該會導致磁碟換出這些扇區，但根據我的經驗，一旦驅動器啟動去最好只是更換它並完成它。