問題タブ [jffs2]

squashfs を使用する buildroot でルート ファイルシステムを作成しました。それは正常に動作し、/home および /etc ディレクトリを保持する overlayfs を作成したいと思います。

この目的のために、いくつかのファイルを含む単純な jffs2 ファイルシステムを作成したいと考えました。

私が使用しているフラッシュ チップは SST25VF064C であるため、消去ブロック サイズは 64 KB であると思われるため、そのフォルダーからファイル システム イメージを作成します。

(驚いたことに、-e 32 または -e 4 を設定しても、結果のバイナリ イメージはまったく変化しませんか???)。それにもかかわらず、先に進み、ホームを含む mtdblock を 64KB に揃えました。フラッシュ レイアウトは次のようになります。

私のボードでは、mtdblock4 を問題なくマウントでき、ファイルの内容を正しく読み取ることができます。ただし、ファイルを変更して保存しようとすると、次のようにvi不平を言います。

ここで、ファイルシステムをアンマウントして再マウントすると、すぐに苦情が発生し始めます。

私のファイルシステムはすでに壊れていると思います...そして、その理由を本当に理解していません..これでどこが間違っているのでしょうか? すべての提案をありがとう..

「df」コマンドを使用すると、jffs2 が常に 388KB の使用済みスペースを表示するのはなぜですか?

640KB と 1024KB の 2 つの mtd パーティションがあります。合計フラッシュを消去した後、常に両方のケースで使用済みスペースとして 388KB が表示されます。

助けてください、なぜこの種の動作を示すのですか?

ユニットが約 3 ～ 4 日間実行された後、ほとんどのユーザー空間プロセスは D 状態になります。ユニットは ARM プロセッサで実行されています。上部の o/p から、D 状態のプロセスがシステム コール「page_fault」および「squashfs_readpage」を待機していることがわかります。最終的に、これはウォッチドッグのリセットにつながります。D-sate に入るプロセスは、回復するのに非常に長い時間がかかります。

以下は、システムに問題が発生した場合のトップ o/p です。

もう 1 つの興味深い観察結果は、システムがこの問題に陥ると、"mtdblockd" プロセスが最上位の o/p で実行されていることを一貫して確認できることです。このユニットではスワップを無効にしています。ユニットに明らかなメモリ リークはありません。

考えられる理由は何か、プロセスが D ステートでスタックしているという考えはありますか?

jffs2 fs で「アトミックなスケジュール設定」のエラーを見た人はいますか? gcd カーネル スレッドにあるようです。正確な修正は何ですか？2.6.39 カーネル上にあります。プリエンプションが構成されていない場合、問題は発生しません。前もって感謝します。

注: カーネルでデバッグを有効にしない別のトレースは、次のように表示されます。

JFFS2 パーティションをルート パーティションとして使用し、コマンド ライン (および fstab) で RO としてマウントします。Montavista 5.0 linux (2.6.18) です。

Linux がアプリケーションに到着したとき、98% の CPU 時間で jffs2_gcd_mtd3 によって約 15 秒間ビジーであることを除いて、すべてが機能します。私の場合、これは受け入れられません。

Linuxコードを検索したところ、RWがマウントされている場合にのみGCスレッドが開始されることがわかりましたが、それでも私の場合は開始されます!

rw をマウントしてあとがきにアンマウントしようとしましたが...

ありがとうございます。

更新: GC デーモンに関する記述が間違っています。エラーで表示されました。この問題の主な原因は、以前の YAFFS2 と比較して、JFFS2 の動作が非常に遅いことです。比較してみると、14MiB の私の ELF 形式のアプリケーションは YAFFS2 から 2 ～ 2.5 秒でロードされましたが、JFFS2 からは約 8 秒かかりました!!! これにより、Linuxをブロックしている何かがあると思いました...

さて、質問は次のように変更されました: JFFS2 が非常に遅くなる原因は何ですか!?!? 繰り返しますが、パーティションは RO でマウントされます。

私たちのシステムでは、jffs2 を使用して、カーネルと initramfs を NAND メモリに書き込みます。より強力な ECC をすぐに使用したいと考えています。しかし、新しい ECC フォーマットは OOB 領域全体を必要とし、JFFS2 では動作しません。

なぜJFFS2を使用する必要があるのか​​ 、まだわかりません。AFAIK カーネルと initramfs は起動時に RAM にコピーされ、RAM から実行されます。それらは頻繁に変更されるわけではありません (更新のため年に数回程度)。

現在、zmodem を介して、busybox を備えた Linux が組み込まれた小さなシステムにいくつかのファイルをアップロードしようとしています。ほとんどのファイルは 9600 ボー接続で長い時間がかかりますが、常に失敗するファイルが 1 つあります ( cramfs_cmc-pu2_v2.45.img )。約 4MB で、最大のものでもあります。アップロードには、zmodem をサポートする Putty フォークであるLe Puttyを使用します。残念ながら、そのマシンの ftp サーバーが正しく動作しないため、ファイルをアップロードする他の方法はありません。

問題は、アップロードが常にこの奇妙なもので終わることです (フィードバックがまったくない状態が数時間続いた後):

フラッシュメモリが不足していると思いましたが、 df はちょうど私に与えます

ファイルシステムが jffs2 であるため、その場合の空き容量の計算はとにかく困難です。

おそらく、その古代のプロトコルでこの問題を解決する方法を考えている人がいるでしょう. 前もって感謝します。

編集：その間、ファイルを多くの小さなファイルに分割し、それらをアップロードしようとしました. 2 つのファイルの後で常に失敗します。これは、十分な空き容量がないという疑いを裏付けています。

dmesg :

jffs2dump:

What is causing this? how can i fix that? Thanks.