ファイルシステム/home/user/meのメタデータでハードドライブの不良セクタが発生すると、ext4すべてのサブディレクトリデータが失われることを意味しますか？
背景：
私はext4ファイルシステムに満足し、データ損失のリスクが高まると主張しながら、「最近」開発された代替手段（BTRFSなど）に変更する意思さえない多くのユーザーを知っています。実際、ext4のコードが今日までにあることを考えると、いくつかの結果が見つかります。昆虫の物語。
この紹介を通して、私の質問は次のようになります。
ext4ブロックデバイスの不良セクタに対するファイルシステムの耐性はどのくらいですか？不良セクタは4Kバイトを消費する可能性があり、その/home/user/me4Kがディレクトリ構造（ディレクトリなど）のより高い場所にあるいくつかのディレクトリ情報を食べると、「混乱」を引き起こす可能性があります。
私はスーパーブロックについて知っています（より基本的な情報源はext4で冗長形式に保たれるため、不良ブロックがそこから回復できると想像していますが、自動的に検出されるかどうかはわかりません）
だから私の質問は次のようになりますext4はメタデータの不良ブロックの欠落を防ぎますか？
私はデータ/ファイルコンテンツの不良ブロックが常にその512/4Kセクタの損失を意味することを知っています（しかし私は解決策としてparchiveを使用しています）。
ベストアンサー1
その問題を少し調査した後「ext4ブロックデバイスの読み取りエラーを処理できる場合」私の初期の結論は次のとおりです。ext4には部分的な重複のみが存在します。
以下は、私が「調査」したext4「セキュリティ機能」で見つけたいくつかのことです。Ext4 Wikiそして
「EXT4ファイルシステムのInode構造」)
- いくつかの例外を除いて、次のようになります。インラインデータまたはインラインデータ
ext4ファイルコンテンツ「データブロック」とファイルシステム「メタデータブロック」をそれぞれ保存します。私が知っている限り、ext4後者には少し修理/重複が必要です。 - メタデータの修正/重複はa) 2010年に導入/追加された新しい項目に依存します。チェックサム機能b) 余分なコピーを持っている主なメタデータ
- そんな」主なメタデータ「（ブロックデバイスの他の部分という意味で）そうです。
ext4スーパーブロック- 情報
block group descriptors。
- チェックサムスーパーブロック、マルチマウント保護、拡張属性、ディレクトリエントリ、HTREEノード、拡張、inode、およびグループ記述子を保護します。スコープ付き（したがって保護される）新
ext4機能は、既存のIBA（間接ブロックアドレッシング）を部分的に置き換えますが、以下のように既存のIBAブロックは保護されません。[IBA] ブロックがゴミでいっぱいではないという信頼性のあるレベルを提供するマジックナンバーやチェックサムもないことに注意してください。
読めないディスクセクタ（512/4K）からext4が回復できるもの
- 損失スーパーブロックそしてブロックグループ記述子、重複したコピーは、全体または一部の特定のブロックグループのディスクに保存されます。
- 読み取れないセクタによってディレクトリエントリが失われることはアクセスできないという意味ではありませんが、ディレクトリに保存されているファイルの内容が失われるという意味でもあります（ファイル名だけが失われます）。これらのファイル（サブディレクトリを含む）は、そのファイルを介して引き続き
filespec<inode-number>アクセスできますdebuge2fs。 - 部品がありません
inode table。各項目索引ノード表ext4（ディスクレイアウトを構成するブロックグループに分割されて記録されるテーブル部分）は256バイト（パディング）を占めます。したがって、読み取れないセクタが1つあるということは、2〜16個のファイルだけが失われることを意味します。さらに、チェックサム機能的inodeテーブルのすべての破損は変更可能でなければなりませんが、必ずしも変更することはできませんが、無視してはいけません。
ext4予防不能に見える不良セクタによって発生する問題は何ですか？
- inode、ディレクトリエントリ、範囲など、重要でないメタデータはIBAで保護されていません。
- インデックスノード：前述のように、inodeは256バイトを占め、ファイルデータを構成するブロックへのコアハンドルです。つまり、2〜16個のファイルへのアクセスが失われます（主にファイルサイズとは無関係）。
- ディレクトリエントリ：不良セクタのために欠落している場合は、内部のすべてのファイルのファイルパスにファイル名部分がありません。一方、不良セクタのサイズは512または4Kバイトであり、ディレクトリハッシュ機能が占めるファイル名とスペースが損失の程度に影響します。また、私が理解しているように、ディレクトリハッシュは本質的に冗長性を提供します（ただしこれを保証することはできません）。
- スコープ：inode自体の喪失など、スコープツリー内の一部の情報の喪失は、ファイルの内容を構成するデータブロックへのアクセスに影響を与えるため、約1つのファイルが失われます。
- IBAブロック：（範囲を参照）+上記のように、部分的な損傷に対する脆弱性も増加します（ただし、これが質問の主な焦点ではありません）。
別の使用方法
不良セクタに対する抵抗に関してディスクレイアウトの列挙された課題のいくつかをテストして実証するには、ext4次のツールが役立ちます。
debugfs <blockdev>filespec（問題がある場合はファイルパスまたはinode番号< >）を介してファイルにアクセスできます。truncate、、、、ddおよび使用するファイルシステムをlosetup作成します。mountmkfs.ext4ext4dumpe2fs、tune2fs情報を提供するdm-setup次のように読み取りエラーをシミュレートする仮想ブロックデバイスを組み立てます。$> dmsetup 生成 badsectordevice << EOF 0 2902リニア/開発/ループ1 0 une 2902 2904 17576 リニア/開発/ループ1 2904 EOF
この例では、ブロックデバイスセクタが 512 でext4ブロックサイズが 1024 であるため、LBA セクタ 2902、2903 が読み取れないことを示しています。