web-dev-qa-db-ja.com

raidz1 vdevにzfsチェックサムエラーがありますが、ディスクにはありません

2台のハードディスクを備えた単一のraidzvdevで構成されるzpoolに保存されているデータをバックアップしています。この操作中にチェックサムエラーが発生し、ステータスは次のようになります。

  pool: tmp_zpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: none requested
config:

    NAME                  STATE     READ WRITE CKSUM
    tmp_zpool             ONLINE       0     0     2
      raidz1-0            ONLINE       0     0     4
        tmp_cont_0        ONLINE       0     0     0
        tmp_cont_1        ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /some/file

私が混乱しているのは、チェックサムエラーがvdevレベルで表示されるが、ディスクレベルでは表示されないことです。おそらく私は注意する必要があります、ハードディスクの1つは内部であり、もう1つは外部です（これは一時的な状況です）。これはハードドライブコントローラーの問題になる可能性がありますか？

影響を受けたファイルを取り戻すために私ができることはありますか？エラーをクリアしてvdevをインポートすると、ディスクの1つだけで劣化しますか？何が起こるかを確認するためにファイルを再度読み取ろうとさえしませんでした。 （何かに影響するかどうかはわかりません。）

更新：エラーをクリアして再試行すると何がうまくいかないのか説明を待つのを諦めたので、先に進んで試してみました。最初にzpool clearを実行しましたが、zpool statusはエラーを示しませんでした。次に、エラーのあるファイル（最後に2つ）を読み取ろうとしましたが、それぞれのブロックが不良/読み取り不能として報告されていました。今回は、zpool statusでチェックサムエラーの増加が見られなくなりました。次に、raidz1 vdev内のディスクの1つをオフラインにしてプロセスを繰り返しましたが、結果は変わりませんでした。合計で、1.6Tのうち2つの128Kブロックを失いました。

回答ステータス：現在、この質問に対する包括的な回答はありません。誰かがそれを書き上げたり、既存のものを編集したい場合は、以下に対処してください。

  1. この状況を引き起こした可能性があるもの。
  2. それについて何ができるでしょうか。
  3. どうすれば防げたのでしょう。

1の場合、理論とその問題は次のように思われます。

  • raidz1よりもraidz2を選択します。問題：raidz2には最低4つのディスクが必要です。冗長性の必要性は明らかですが、冗長性の失敗の解決策がより多くの冗長性であることを繰り返し示唆することは有用ではありません。あなたが持っている冗長性を最もよく使う方法を理解することははるかに役立つでしょう。

  • mirrorよりもraidz1を選択します。問題：一見すると、これらの違いは冗長性ではなく効率にあるようです。ただし、これは間違っている可能性があります。理由：zfsは各ディスクの各ブロックでチェックサムを保存しますが、どちらのディスクも個別のチェックサムエラーを報告しませんでした。これは、すべての不良ブロックについて、2つのディスクに異なるブロックペイロードが含まれ、それぞれに一致するチェックサムがあり、zfsがどちらが正しいかを判断できなかったことを示唆しているようです。これは、2つの異なるチェックサム計算があり、ペイロードがそれらの間で何らかの形で変更されたことを示しています。これは、RAM破損であり、おそらく（確認が必要）raidz1ではなくmirrorを選択すると、1つのチェックサムのみが必要になることで説明できます。

  • 読み取りではなく書き込み中のRAMの破損。上で説明したように、これはもっともらしいようです。問題：書き込み時にこれがエラーとして検出されなかったのはなぜですか？ zfsが書き込み内容をチェックしないということでしょうか？むしろ、異なるディスクに書き込まれるブロックペイロードが同じであるということですか？

2の場合：

  • ディスクには個別のチェックサムエラーがないので、そのような不良ブロックの2つの異なるコピーにアクセスするためのzfsの低レベルの方法はありますか？

3の場合：

  • mirror over raidz1がこの状況を防いだことは明らかですか？

  • このzpoolのスクラブで問題が検出されたと思います。私の場合、いくつかのデータを移動していて、実際にこのzpoolを読み取る前に、2つのディスクの冗長性があると考えてソースデータを破棄しました。ここでの教訓は、その内容を信頼する前にzpoolをスクラブすることでしょうか？確かにスクラブは便利ですが、それは必要ですか？たとえば、raidz1の代わりにmirrorを使用してスクラブが必要でしょうか？

hard-drivefilesystemszfscorruptionchecksum
6
Matei David

これはraidz1（およびRAID5）の問題です。ディスク上のデータが変更されても、ドライブ障害が発生してZFSまたはRAIDコントローラーにエラーの原因となったドライブを通知しない場合、どのドライブが正しいかを知ることはできません。 raidz2（およびそれ以降）またはRAID6を使用すると、再構築のために無視するドライブを決定できるドライブのクォーラムを取得できます。

ここでの唯一の解決策は、バックアップコピーを復元するか、ファイルに/dev/nullを書き込むことによって、ファイルを上書きすることです。

3
longneck

私は同様の問題に直面しています。それが役立つかどうかはわかりませんが、FreeBSD開発者からのvdevレベルのチェックサムエラーに関するこの関連記事を見つけました。

https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046330.html

Vdev_raidz.cがどのリーフvdevが原因であるかを判別できない場合、チェックサムエラーはリーフではなくraidzvdevに表示されます。これは、2つ以上のリーフvdevが同じブロックに対して不良データを返す場合に発生する可能性があり、これも回復不能なデータエラーにつながります。回復不能なデータエラーが発生しているようです。おそらくそれがあなたに起こったことです。

ZFSの微妙な設計バグにより、vdev_raidz.cがチェックサムエラーの原因となった子を特定できない場合もあります。ただし、raidzvdevにミラーの子がある場合にのみ発生することを確認しました。これは、子がスペアであるか、vdevを置き換える場合にのみ発生する可能性があります。スペアをアクティブにしましたか、それとも手動でvdevを交換しましたか？

私自身、zpool.cacheファイルを削除し、プールをインポートしてそのzpool.cacheファイルを再生成することを検討しています。

0
user260467