☰

クラッシュ後に異常に高いブロック数/サイズが原因でe2fsckが失敗する

tag-icon • tag-icon ext4 fsck crash
クラッシュ後に異常に高いブロック数/サイズが原因でe2fsckが失敗する

サーキットブレーカを操作した後、私のRaspberry Piはカーネルパニックで起動を停止し始めました（ここ）。これはRaspbianを実行するRaspberry Piなので、ext4SDカードのデフォルトパーティションで実行されます。以下を使用してPCから回復しようとしました。

sudo e2fsck -f -y -v /dev/sdx2

しかし、これは最終的に奇妙な出力のために失敗します。

Error writing block 137439060017 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error reading block 183472412950529 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 183472412950529 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Inode 13329, i_size is 4096, should be 549755817984.  Fix? yes
Inode 13607, i_size is 69632, should be 137439023104.  Fix? yes
Error reading block 36983963385857 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 36983963385857 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error reading block 179632729097217 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 179632729097217 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error reading block 17592186080054 (Invalid argument) while reading directory block.  Ignore error? yes
Force rewrite? yes
Error writing block 17592186080054 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error storing directory block information (inode=17449, block=0, num=134507168): Memory allocation failed
/dev/sdx2: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted
/dev/sdx2: ***** FILE SYSTEM WAS MODIFIED *****

ここで心配する必要がある2つのことがあります。

  • inodeサイズとブロックサイズがものすごく高いようです（16GB SDカードについて話しています）。
  • e2fsck終了Memory allocation failed- 32GB RAMを搭載したPCではほとんど無料です。実際に失敗する前に利用可能なRAMを占有します。

一時ファイルディレクトリを設定しようとしましたが、同じ結果が得られました（一部のファイルがe2fsckそこに書き込まれ、ターゲットディレクトリが+ 250 GBの空き容量があるマウントにありました。空きRAMを占有して失敗しました）。

影響を受けたパーティションのデフォルトのファイルシステムパラメータが一部破損しているようです。それを診断して削除する方法は？

答え1

e2fsck -fyを実行すると、最後のいくつかのエラーメッセージだけでなく、e2fsckレコード全体も保存する必要があります。おそらく、ファイルシステムが重大に破損しており、-yオプションはとにかく続行することを意味します。

ブロックグループ記述子が重大に破損しているようです。だから、inodeテーブルの場所は奇妙です。 E2fsckはおそらく問題を解決しようとしましたが、何らかの理由で問題を解決できませんでした。 「-y」は、それにもかかわらず実行され続けるという意味です。したがって、人々がバグレポートを送信するときに最後のいくつかのエラーだけでなく、e2fsckレコード全体を送信することを常にお勧めします。

答え2

早く見ましたe2fsckソース、私の考えでは、ある場所では「メモリ割り当てに失敗しました」メモリ割り当てエラーにより実際にエラーが発生しない場合があります。

エラー文字列は[src]/lib/ext2fs/ext2_err.et.in定数に基づいて定義されますEXT2_ET_NO_MEMORY。これはコードのさまざまな場所から返すことができます[src]/e2fsck/。以下は次の例ですea_refcount.c。

errcode_t ea_refcount_increment(ext2_refcount_t refcount, blk_t blk, int *ret)
{
    struct ea_refcount_el   *el;

    el = get_refcount_el(refcount, blk, 1);
    if (!el)
        return EXT2_ET_NO_MEMORY;

get_refcount_el()同じファイルから：

static struct ea_refcount_el *get_refcount_el(ext2_refcount_t refcount,
                          blk_t blk, int create)
{
    int low, high, mid;

    if (!refcount || !refcount->list)
        return 0;

これがnullを返す唯一の理由ではなく、割り当て失敗と直接的な関係がないように見える唯一の理由でもありません。

実際にこれを証明するにはもう少し調査する必要がありますが、システムメモリを実際に消費しないというあなたの声明と一致します。

この場合、問題は混乱しているか破損しているSDカードコントローラの不明瞭で予測不可能な可能性に関連している可能性がありますが、それをキャッチするために一種の完全なチェックやその他の対策を講じる必要があるため、まだe2fsckのバグに対応しています。問題は単に「申し訳ありませんが、デバイスが破損している」（事実である可能性が高い）または「メモリ不足」（事実ではない可能性が高い）であっても同じです。この問題を報告できます（「これらのプログラムでエラーが発生した場合は、Ted Ts'oにお問い合わせください。[Eメール保護]または[Eメール保護]」- 私はTTがLinuxカーネル開発者だと思います。）このQ＆Aを参照してください。

それ以外は、そのカードの内容を忘れて破壊的な読み書きテストを実行する方が良いと思います。

badblocks -v -w -b 1048576 -c 16 /dev/sdx

覚えておいて、これ破壊的なテスト - すべてのデータが失われます。 BadblocksはSDカードの実際の不良ブロックのリストを生成するのには役に立ちませんが（ウェアレベリングのために物理的な物理アドレスを報告しません）、カードが不良かどうかを知らせることができます。この方法で16GBのカードをテストするのに1時間もかかりません。

関連情報