ZFSがディスクのダフセクターで何もしないのはなぜですか？
ZFSプールからの読み取り中にI/Oエラーが発生した場合、次の2つのことが起こるという印象を受けました。
- 障害は、関連するデバイスのREADまたはCKSUM統計のいずれかに記録され、プールレベルに向かって上方に伝播します。
- 冗長データは、要求されたブロックを再構築し、要求されたブロックを呼び出し元に返し、duffドライブがまだ機能している場合は、ブロックをそれに書き換えるために使用されます[〜＃〜]または[〜＃ 〜]
- 読み取りエラーを修正するための冗長データが利用できない場合、I/Oエラーが返されます。
ミラー設定のディスクの1つが不良セクタを開発したようです。それ自体は憂慮すべきことではありません。そのようなことが起こり、それがまさに私が冗長性を持っている理由です（正確には2面ミラー）。プールをスクラブしたり、特定のディレクトリ内のファイルを読み取ったりするたびに（どのファイルに問題があるかを正確に特定することはまだできていません）、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
これはかなり最新のDebianWheezy、カーネル3.2.0-4-AMD64＃1 SMP Debian 3.2.63-2 x86_64、ZoL0.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
そこに普通のこと明白に何もありません。これはエンタープライズドライブであるため、5年間の保証およびは24時間年中無休で動作します（つまり、40,000時間以上の動作で信頼性が高いことを意味します）これまでのところ、そのベルトの下で10,000時間弱まで）。属性187Reported_Uncorrectの番号5に注意してください。そこに問題があります。また、Start_Stop_CountとPower_Cycle_Countの値がそれぞれ100未満とかなり低いことに注意してください。
この場合は関係ないと思いますが、システムにはECCRAMがあります。
プール上のルートファイルシステムのデフォルト以外のプロパティは次のとおりです。
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が自動的に書き換えないのはなぜですか？ドライブによる再配置がトリガーされることを願っています。
ATAドライバーは、エラーを受け取ったときに読み取り操作を数回再試行してから、エラーをファイルシステムドライバーに返していると思われます。
これが意味するのは、ZFSファイルシステムドライバーが読み取りの結果を取得するまでに、データはすべてそこにあり、正しいですが、通常よりも少し時間がかかった可能性があります。もちろん、平均よりも長いレイテンシーのエラーカウンターはないため、何もログに記録されません。
Reported_UncorrectのSMART値が0でないという事実は、SATAケーブルまたはSATAコントローラーが不安定であるとは対照的に、障害の原因がディスク自体であると私に思わせます。
この場合、ブロックデバイスドライバーが何度も再試行した後でも、ディスクは最終的にはさらに停止し、読み取りに失敗し始める可能性があります。そのため、私のアドバイスはディスクを交換することです。
長いSMARTテストをトリガーすると、影響を受けるブロックで失敗する可能性があります。エラーを解消したい場合は、これらのブロックを書き換えると（たとえば、ddを使用）、ディスクでこれらのセクターがスワップアウトされます。しかし、私の経験では、ドライブが動き始めたら、それを交換してそれで済ませたほうがよいでしょう。
SolarisでZFSRAIDを使用した不良SCSIディスクがありました。ログファイルをスキャンしてエラーメッセージに関する情報を探し、ディスクが不良であるという証拠を収集し、Oracleにハードウェアのメンテナンスでカバーしてもらいました。エラーログの特定の文字列に対してgrepを実行しましたが、ディスクエラーを示すこれらの行がコンソール画面に表示されます。 「Explorer」（Solarisのシステムログおよびレポートツール）を実行してOracleに送信したところ、ディスクにエラーはなかったとのことでした。しかし、私は私の画面履歴にそれらを持っていました。確認したところ、実際にディスク上のログから削除されていました。
これが何が起こっていたかです... ZFSは、ゼロのデータエラーではなく、ゼロのファイルシステムエラーを約束します。重大な破損が発生すると、トランザクションをロールバックし、ファイルシステムの整合性を良好にするために必要なことをすべて実行します。その結果、ファイルの更新は、破損する前に以前のバージョンのファイルにロールバックすると失われるため、データが失われる可能性があります。しかし、ファイルシステムにはエラーがありません。
おそらく単純なエラーの場合、ZFSは別の試行でデータをロールバックして再書き込みできますが、ディスクの動作が悪いという深刻なケースでは、データが回復および書き込みされていないキャッチ22に入る可能性があります。ディスクエラーに関する証拠を収集する必要がある場合は、それらを画面に表示し、ZFSトランザクションのロールバックによってデータがリセットされる可能性があるディスクに存在する証拠に依存しないでください。