Hdd不良セクターが/home/user/me
fsのext4
のメタデータで発生した場合、それはすべてのサブディレクトリのデータ損失を意味しますか?
背景:
私は多くのユーザーがext4ファイルシステムに満足しており、さらに「最近」開発された代替手段(BTRFSなど)に変更することに消極的であり、データ損失のリスクが高いと主張しています。確かに、ext4のコードが今日の時間である場合、 バグは話す を見つける結果がいくつかあります。
この紹介で、私の質問は:
ブロックデバイスの不良セクターに対するext4
ファイルシステムの耐性はどのようなものですか。不良セクターは4Kバイトを飲み込む可能性があります。4Kがディレクトリ構造の上位にあるディレクトリ情報(つまり、/home/user/me
ディレクトリ)を飲み込んだ場合、私はそれを「大混乱」に陥らせると思います。
スーパーブロックがあることを知っています(さらに基本的な情報源がext4で冗長な形式で保持されるため、不良ブロックをイメージングするとそこで修復できますが、自動的に検出されるかどうかはわかりません)。
だから私の質問:ext4はメタデータの不良ブロックの紛失に抵抗できますか?
データ/ファイルコンテンツの不良ブロックは、常にそれらの512/4Kセクターを失うことを意味します(ただし、そこでの対策としてparchiveを使用しています)。
問題を調査した後 "if ext4
can be read error from a block devices"私の予備的な結論は:only部分的な冗長性がext4に存在します
ここに私の「調査」ext4
の「安全機能」のいくつかの調査結果があります( Ext4 wiki および "EXT4ファイルシステムのノード構造" に基づく)
ext4
はファイルの内容「データブロック」とファイルシステムの「メタデータブロック」を別々に格納します。私の理解する限りでは、ext4
は、後者に関して、一部の修理/冗長性の準備のみをとります。ext4
スーパーブロックblock group descriptors
情報。ext4
機能は、古い間接ブロックアドレス(IBA)に一部取って代わるように保護されています)ですが、古いIBAブロックは、次のように保護されていません。[IBA]ブロックがゴミでいっぱいではないというレベルの信頼を提供するマジックナンバーもチェックサムもないことに注意してください。
<inode-number>
のfilespec
debuge2fs
を介して引き続きアクセスできます。inode table
の一部の損失。 inodeテーブルの各エントリ(分割されるテーブルと、ext4
ディスクレイアウトを形成するブロックグループに書き込まれるパーツ)は、256バイトを占有します(埋め込み) 。したがって、読み取り不可能なセクターは、2〜16個のファイルのみが失われることを意味します。さらに、checksum機能を使用すると、iノードテーブル内の破損は必ずしも修正可能とは限りませんが、通知されないわけではありません。ext4
は防御できないようですext4
ディスクレイアウトの列挙された課題のいくつかをテストして証明するために(不良セクターへの抵抗に関して)、次のツールは便利です
debugfs <blockdev>
を使用すると、filespecを介してファイルにアクセスできます(ファイルパス、または< >
のiノード番号を介した問題の場合)truncate
、dd
、losetup
、mount
およびmkfs.ext4
を使用して、ext4
ファイルシステムを作成し、操作します。dumpe2fs
、tune2fs
は情報を提供します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は読み取れません。