web-dev-qa-db-ja.com

フラッシュデバイスでこのFSエラーをデバッグする方法を教えてください。

組み込みLinuxデバイスへのコンソールアクセスがあります。このデバイスにはフラッシュメモリ部分があり、その一部はFATファイルシステムとしてパーティション化されています。

その実行中のlinux-2.6.31。

ただし、最近コンソールにこれらのエラーが表示され、FATファイルシステムが読み取り専用になります。

111109:154925 FAT: Filesystem error (dev loop0)
111109:154925 fat_get_cluster: invalid cluster chain (i_pos 0)
111109:154925 FAT: Filesystem error (dev loop0)
111109:154925 fat_get_cluster: invalid cluster chain (i_pos 0)

これがなぜ起こったのか理解できませんか？根本的な原因は何ですか？そして、修正は何ですか？デバイスでこの問題の考えられる根本的な原因を調査する方法を教えてくれる回答をいただければ幸いです。

linuxfilesystemsfat32
6
Ankur Agarwal

ビットアンドバイトレベルで実際に起こったことは、ファイルアロケーションテーブルの4バイト（またはそれ以上）が0x00バイトで上書きされたことです。

ファイルアロケーションテーブルのしくみについて簡単に説明します。これは、値が同じ配列のインデックスである配列と見なすことができます。したがって、ファイルの最初のクラスター番号がiであることがわかっている場合、次のクラスター番号はfat[i]で、その後のクラスター番号はfat[fat[i]]となります。 （これは少し簡略化されています）。チェーンの最後に到達したことを知らせるために、有効なクラスター番号の代わりに特別なEOC値が使用されます。

ディスクからFATファイルを読み取るには、ファイルが格納されているクラスター番号が順番に必要です。ディレクトリエントリは、最初のクラスタ番号（i）を示します。残りは、EOC値が検出されるまで、チェーンfat[i]、fat[fat[i]]などをたどって見つけることができます。次に、クラスター番号から各クラスターのディスク上の位置を取得し、各クラスターをメモリに読み取り、それらを連結するのは簡単な計算です。

fat_get_cluster: invalid cluster chainエラーが発生 値0x00000000が見つかった場合 このようなチェーンの後に続きます。これは起こらないはずです。新しい有効なクラスター番号またはEOC値のいずれかである必要があります。これが発生すると、チェーンをさらにたどる方法がないため、ファイルを読み取ることができなくなります。 （0x00000000値は、クラスターを空きとしてマークするために使用されます。クラスター0は、データの格納に使用されることはないため、あいまいさはありません）

i_posには0が指定されているため、ケースが特殊なケースになる可能性があります。このメッセージを受け取ったとき、それは大きな数でした。 カーネルソース 言う：

    loff_t i_pos;           /* on-disk position of directory entry or 0 */

したがって、i_posはクラスター番号ではなく、ディスク上の位置です。ゼロのときの意味はわかりません。

編集：何が原因であるかについては、推測しかできませんが、いくつかの可能性があります：

  1. FATドライバーのバグ。
  2. 宇宙線 。
  3. ウイルスまたは その他の悪意のあるソフトウェア 。
  4. おそらく、2つのプログラム/ドライバーが何らかの理由で同じFATに同時に書き込みと読み取りを行っていた場合、それらは互いにつまずく可能性があります。それが可能かどうかわからない。
  5. 間違ったときにハード電源がオフになります。フラッシュドライブは変更を書き込む前にブロックをゼロにする必要があるため、理論的には消去直後に電源をオフにするとこの結果が発生します。ただし、ほとんどのドライブでこれを防ぐために failsafes があります。
  6. ユーザーエラーまたは妨害行為（例：dd if=/dev/zero of=/dev/sda1 bs=512 count=1 seek=32-自宅でこれを試さないでください！）

FATファイルシステムドライバは、冗長性のために2つのFATテーブルを最新の状態に保ちます。2つ目は 最初の直後 です。それらが同一であるかどうかを確認することは、何が起こったかの手がかりを与えるかもしれません。クラスターチェーンを壊す値のみが異なる場合、少なくとも1と3が「適切に」機能することが期待されるため、何らかの形で直接改ざんされる可能性が高くなります。

しかし、現代のほとんどのドライバーは、FATテーブル全体をRAMに保持し、変更される部分を両方のオンドライブコピーに戻すように書き込みます。したがって、時間の差は、通常の使用時にすばやく静かに「修正」された可能性があります。これは、経験に基づく推測にすぎないことに注意してください。

結局のところ、状況についてのさらなる情報なしに確実に知ることは非常に困難であり、それでも推測である可能性があります。理想的な状況は、問題を確実に再現できる場合です。次に、「変更前」と「変更後」のFATテーブル（およびFATヘッダー）を比較して、変更点と変更点を正確に確認し、配置と変更内容のヒントを探します。

6
Lauritz V. Thaulow

何らかの理由でFAT32が破損しています。 FSプラットフォームで現在USBホストの問題をデバッグしているため、USBスティックが壊れてARMになることがよくあります。テスト後、次のコマンドを発行します。私のデスクトップマシンから（Ubuntu 11.04）：

$ Sudo fsck.msdos -aw /dev/sdb1

参照： https://askubuntu.com/questions/31614/how-to-delete-edit-files-from-readonly-filesystem

5
m-ric

発生しているエラー無効なクラスターチェーンおよびファイルシステムエラーは、それがファイルシステムエラーであることを明確に示しています。

FATのWikipediaエントリは言う：

パーティションは、同じサイズのクラスター、連続したスペースの小さなブロックに分割されます。クラスターサイズは、使用されているFATファイルシステムの種類とパーティションのサイズによって異なりますが、通常、クラスターサイズは2 kB〜32 kBの間です。各ファイルは、そのサイズに応じて、これらのクラスターの1つ以上を占有する場合があります。したがって、ファイルはこれらのクラスターのチェーンで表されます（単一リンクリストと呼ばれます）。ただし、これらのクラスターは必ずしもディスクの表面に互いに隣接して格納されているわけではなく、データ領域全体で断片化されていることがよくあります。

ファイルアロケーションテーブル（FAT）は、パーティション上の各クラスターにマップするエントリのリストです。各エントリは、次の5つのうちの1つを記録します。

  • チェーン内の次のクラスターのクラスター番号
  • チェーンの終わりを示すクラスターチェーンの特別な終わり（EOC）エントリー
  • 不良クラスタをマークする特別なエントリ
  • クラスターが未使用であることを示すゼロ

これ リンクは、誰かがfsckを使用してメモリカードに関する同様の問題を解決したことを示しています。

1
Sachin Divekar