ZFSがディスクのダフセクターで何もしないのはなぜですか？

ZFSプールからの読み取り中にI / Oエラーが発生すると、次の2つのことが発生するという印象を受けました。

1. 障害は、関連するデバイスのREADまたはCKSUM統計のいずれかに記録され、プールレベルに向かって上方に伝播します。
2. • 冗長データは、要求されたブロックを再構築し、要求されたブロックを呼び出し元に返し、ダフドライブがまだ機能している場合は、ブロックをブロックに再書き込みするために使用されます。または、
   • 読み取りエラーを修正するための冗長データがない場合は、I / Oエラーが返されます。

ミラーセットアップのディスクの1つで不良セクターが発生しているようです。それ自体は驚くべきことではありません。そのようなことが起こり、それがまさに私が冗長性を持っている理由です（正確には、双方向ミラーです）。プールをスクラブするか、特定のディレクトリのファイルを読み取るたびに（どのファイルに問題があるかを正確に特定するためにまだ気にしていません）、次のように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ドライブで実行すると、書き込み-読み取り-検証がオンになっていると報告されます（これは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時間365日の動作が保証されています（これまでのところ、1万時間弱と比較して、4万時間以上の動作で信頼できることを意味します）。属性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が自動的に書き換えず、ドライブによる再配置がトリガーされないのはなぜですか？

ATAドライバーがエラーを受け取ったときに、ファイルシステムドライバーにエラーを返す前に、読み取り操作を数回再試行していると思います。

これが意味することは、ZFSファイルシステムドライバーが読み取りの結果を取得するまでに、データはすべてそこにあり、正しいのですが、通常よりも少し時間がかかる可能性があります。もちろん、平均よりも高いレイテンシのエラーカウンターはないため、何も記録されません。

Reported_UncorrectのSMART値が0ではないという事実は、SATAケーブルまたはSATAコントローラーが不安定であることとは対照的に、障害の原因がディスク自体であると疑っています。

これが事実である場合、ブロックデバイスドライバーが試行している再試行回数が多くても、ディスクは最終的にさらに死に、読み取りに失敗し始める可能性があります。そのため、私のアドバイスはディスクを交換することです。

長いSMARTテストをトリガーすると、影響を受けるブロックで失敗する可能性があります。エラーを解消したい場合は、それらのブロックを書き換えると（たとえば、ddを使用して）、ディスクがこれらのセクターをスワップアウトするはずですが、私の経験では、ドライブが起動すると移動するには、単にそれを置き換えて、それで完了するのが良いです。

SolarisでZFS raidを使用した不良のSCSIディスクがありました。エラーメッセージの情報がないかログファイルをスキャンして、ディスクが不良である証拠を収集し、ハードウェアメンテナンスでOracleにカバーさせました。エラーログの特定の文字列に対してgrepを実行すると、ディスクエラーを示すこれらの行がコンソール画面に表示されます。「エクスプローラ」（Solarisのシステムログおよびレポートツール）を実行してOracleに送信したところ、ディスクにエラーはなかったとのことでした。しかし、私は自分の画面履歴にそれらを持っていました。私がチェックしたところ、実際にディスク上のログから削除されました。

ここで何が起こっていたのか... ZFSは、ゼロのデータエラーではなく、ゼロのファイルシステムエラーを約束します。深刻な破損が発生した場合、トランザクションをロールバックし、ファイルシステムの整合性を良好にするために必要なことを何でも行います。その結果、破損する前にファイルの以前のバージョンにロールバックすると、ファイルの更新が失われるため、データが失われる可能性があります。ただし、ファイルシステムにエラーはありません。

おそらく単純なエラーの場合、ZFSは別の試みでデータをロールバックして再書き込みできますが、ディスクの動作が悪い深刻なケースでは、データが回復および書き込まれていないcatch-22に入る可能性があります。ディスクエラーに関する証拠を収集する必要がある場合は、それらを画面に表示し、ZFSトランザクションのロールバックによってデータがリセットされる可能性があるディスクに存在する証拠に頼らないようにします。