web-dev-qa-db-ja.com

ext4ファイルシステムは不良セクター(読み取り不可)に耐えることができますか?

Hdd不良セクターが/home/user/me fsのext4のメタデータで発生した場合、それはすべてのサブディレクトリのデータ損失を意味しますか?

背景:
私は多くのユーザーがext4ファイルシステムに満足しており、さらに「最近」開発された代替手段(BTRFSなど)に変更することに消極的であり、データ損失のリスクが高いと主張しています。確かに、ext4のコードが今日の時間である場合、 バグは話す を見つける結果がいくつかあります。

この紹介で、私の質問は:

ブロックデバイスの不良セクターに対するext4ファイルシステムの耐性はどのようなものですか。不良セクターは4Kバイトを飲み込む可能性があります。4Kがディレクトリ構造の上位にあるディレクトリ情報(つまり、/home/user/meディレクトリ)を飲み込んだ場合、私はそれを「大混乱」に陥らせると思います。

スーパーブロックがあることを知っています(さらに基本的な情報源がext4で冗長な形式で保持されるため、不良ブロックをイメージングするとそこで修復できますが、自動的に検出されるかどうかはわかりません)。

だから私の質問:ext4はメタデータの不良ブロックの紛失に抵抗できますか?

データ/ファイルコンテンツの不良ブロックは、常にそれらの512/4Kセクターを失うことを意味します(ただし、そこでの対策としてparchiveを使用しています)。

5

問題を調査した後 "if ext4 can be read error from a block devices"私の予備的な結論は:only部分的な冗長性がext4に存在します

ここに私の「調査」ext4の「安全機能」のいくつかの調査結果があります( Ext4 wiki および "EXT4ファイルシステムのノード構造" に基づく)

  • インラインデータ または インラインデータ のような例外的なケースはほとんどありませんが、ext4はファイルの内容「データブロック」とファイルシステムの「メタデータブロック」を別々に格納します。私の理解する限りでは、ext4は、後者に関して、一部の修理/冗長性の準備のみをとります。
  • メタデータの修復/修正は、a)2010年に新しく導入/追加された チェックサム機能 およびb)重要なメタデータ
  • このような「重要なメタデータ」(ブロックデバイスのさまざまな部分にいるという意味で)は。
    1. ext4スーパーブロック
    2. block group descriptors情報。
  • チェックサムスーパーブロック、複数マウント保護、拡張属性、ディレクトリエントリ、HTREEノード、エクステント、iノード、およびグループ記述子を保護します。エクステント(したがって、新しいext4機能は、古い間接ブロックアドレス(IBA)に一部取って代わるように保護されています)ですが、古いIBAブロックは、次のように保護されていません。

    [IBA]ブロックがゴミでいっぱいではないというレベルの信頼を提供するマジックナンバーもチェックサムもないことに注意してください。

Ext4が読み取り不能なディスクセクターから回復できるもの(512/4K)

  • SuperblockおよびBlock Group Descriptorsの損失。これらは、ディスク上のすべてまたは一部の特定のブロックグループに冗長コピーが格納されています。
  • 読み取り不可能なセクターのためにディレクトリエントリが失われたとしても、アクセスが失われたことを意味するわけではなく、さらにディレクトリに保存されているファイルの内容も失われます(名前だけが失われます)。ファイル(サブディレクトリを含む)は、<inode-number>filespecdebuge2fsを介して引き続きアクセスできます。
  • inode tableの一部の損失。 inodeテーブルの各エントリ(分割されるテーブルと、ext4ディスクレイアウトを形成するブロックグループに書き込まれるパーツ)は、256バイトを占有します(埋め込み) 。したがって、読み取り不可能なセクターは、2〜16個のファイルのみが失われることを意味します。さらに、checksum機能を使用すると、iノードテーブル内の破損は必ずしも修正可能とは限りませんが、通知されないわけではありません。

不良セクタに起因するトラブルは何ですかext4は防御できないようです

  • iノード、ディレクトリエントリ、エクステントを含む重要なメタデータではなく、IBAは保護されません。
  • inodes:前述のように、inodeは256バイトを取り、ファイルデータを構成するブロックへのコアハンドルであるため、2から16ファイルまでのアクセスが失われます(ほとんどの場合、ファイルに関係ありません)。サイズ)。
  • ディレクトリエントリ:不良セクタが原因で失われた場合、内部のすべてのファイルへのファイルパスでファイル名の部分が失われることを意味します。一方で不良セクタのサイズ512または4Kバイト、およびディレクトリハッシュ機能によって使用されるファイル名とスペースは、損失の範囲に影響を与えます。また、ディレクトリハッシュは本質的に冗長性を提供することを理解しています(ただし、これは保証できません)。
  • エクステント:エクステントツリーで情報の一部が失われると、iノード自体が失われると、ファイルのコンテンツを構成するデータブロックへのアクセスが危うくなり、おおよそ1つのファイルが失われることになります。
  • IBAブロック:(範囲を参照)+前述のように、部分的な破損に対しても脆弱性が増加します(ただし、これは質問の主な焦点ではありませんでした)。

さらに使用される方法

ext4ディスクレイアウトの列挙された課題のいくつかをテストして証明するために(不良セクターへの抵抗に関して)、次のツールは便利です

  • debugfs <blockdev>を使用すると、filespecを介してファイルにアクセスできます(ファイルパス、または< >のiノード番号を介した問題の場合)
  • truncateddlosetupmountおよびmkfs.ext4を使用して、ext4ファイルシステムを作成し、操作します。
  • dumpe2fstune2fsは情報を提供します
  • dm-setupは、次のような読み取りエラーをシミュレートする仮想ブロックデバイスをアセンブルします。
    $> dmsetup create badsectordevice << EOF 
     0 2902 linear/dev/loop1 0 
     2902 2 error 
     2904 17576 linear/dev/loop1 2904 
     EOF 
    
    例では、ブロックデバイスセクターが512であり、ext4ブロックサイズが1024であるため、LBAセクター2902、2903は読み取れません。
3