問題タブ [jffs2]

jffs2 (mtd-utils バージョン 1.5.0、mkfs.jffs2リビジョン 1.60) の最小消去ブロック サイズは 8KiB のようです:

ただし、at25df321a で Linux 3.10 を実行しています。

消去ブロックのサイズはわずか 4KiB です。

mtd システムに複数の消去ブロックを 1 つとして扱わせる方法はありますか? 多分いくつかのioctlまたはモジュールパラメータ？

より大きな消去ブロック サイズで jffs2 イメージをフラッシュすると、多くのカーネル エラー メッセージが表示され、ファイルが見つからず、時にはパニックになります。

回避策

flasherase --jffs24KiB の消去ブロック サイズにもかかわらず、動作するファイル システムが得られることがわかりました。そのため、ファイルをハッキングしたところmkfs.jfss2.c、結果の画像は正常に機能しているようです。私はそれにいくつかのテストを与えます。

特別な USB デバイスにアクセスする必要があるプログラムを開発しています。この USB デバイスはファイル システム内の通常のファイルとして機能するため、このファイルを O_DIRECT フラグで開く必要があります。次のように:

プログラムはPC環境でうまく動作します。しかし、openwrt を使用して組み込みボードに移植すると、「open」関数は EINVAL 22 /* 無効な引数 */ を返します。

• カーネル構成で O_DIRECT サポートが選択されています。
• openwrt のファイルシステムは squashfs と jffs2 です。
• USB デバイスのファイルシステムはファットで、/media/aegis ディレクトリにマウントされます。
• ボードの ARCH は mips です。

カーネルの次の関数からエラーが返されるようです:

O_DIRECT は jffs2 ではサポートされておらず、fat ではサポートされていることが知られています。/media/aegis 内のファイルを操作する場合、fat の a_ops が使用されていると思いますが、期待どおりにプログラムが実行されません。

JFFS2 パーティションから起動する Linux (3.4.31+) 組み込みシステムを使用しています。他のファイルの削除中に停電が発生すると、ファイルが破損するという問題が頻繁に発生します。プラットフォームのアップグレード手順中に発生します。以下は、アップグレードの簡単な手順です。

1. アップグレード先のファイル システムの rootfs.squashfs イメージを含む tar.gz (他のファイルの中でも) をダウンロードし、イメージの md5 チェックサムを確認します。
2. アップグレードの実行に必要な最小限のツール セットを備えた小さな JFFS2 パーティションから Linux を起動します。
3. アップグレードする必要がある大きなパーティションをマウントします。
4. 大きなパーティションに格納されている rootfs.squashfs をマウントします。
5. 一部の移行されたデータ ファイル、rootfs.squashfs イメージなどを除いて、大きなパーティションからすべてのファイルを削除します。
6. マウントされた rootfs.squashfs からすべてのファイルを大きなパーティションにコピーします
7. 大きなパーティションから起動

上記の電力損失は 5. ステップで発生します。rootfs.squashfs は読み取り専用としてマウントされ、アップグレード中に変更されることはありません。このファイルが破損しても、デバイスの電源を入れた後、ファイルの md5 チェックサムが異なり、サイズは変更されず、イメージはマウントできますが、このイメージから一部のファイルを読み取ることができません。

このファイルが破損するのはなぜですか? JFFS2 はこの種のシナリオに対処すべきではないでしょうか? この状況から回復する方法はありますか？

NOR フラッシュに jffs2 をマウントする際に 2 つの問題に直面しています。

rootfs として squashfs を使用してボードを実行しており、次のように jffs2 を別の mtdblock にマウントしようとしました。
mount -t jffs2 /dev/mtdblock6 /tmp/jffs

その後、mtdblock をアンマウントして再度マウントしましたが、コピーしたばかりのファイルが消えてしまいました。

/dev/mtd6 または /dev/mtdblock6 をダンプしてフラッシュ ブロックが書き込まれていることを確認しましたが、それらのファイルは再マウント後に表示されません。

=====
printk ログを開いたところ、マウントされたフォルダーにファイルを配置すると、次のメッセージが表示されました。
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00120814: 0x0219 instead Node totlen on flash (0x0000000c) != totlen from node ref (0x00000044)

mtdblock を再マウントしようとすると、以下のメッセージが表示されます。
JFFS2 notice: (608) jffs2_get_inode_nodes: Node header CRC failed at 0x0e0050. {0000,9600,01e88b11,01000000}

spi-nor チップを使用し、JFFS2 fs として 16M パーティションを 1 つ作成しました。14M のストレージを使用する必要があるという奇妙なことがわかりましたが、df を使用して確認すると、7M しか使用されていないことが示されます。

別の 2M ファイルをこのパーティションにコピーした後:

1M 以上のストレージしか使用されていないことがわかります。

この問題も見つかった人はいますか？

ありがとう、

カーネル 2.6.33.7 の mpc8309-twr ボードで作業しています。RAM ディスク ファイル システム (rootfs.ext2.gz.uboot) で rootfs イメージを作成しているときに、ファイル システムをマウントでき、ボードは正常に起動できます。 .

VFS: デバイス 31:1 にマウントされたルート (jffs2 ファイルシステム)。未使用のカーネル メモリを解放しています: 168k init 警告: 初期コンソールを開けません。カーネル パニック - 同期していません: 初期化が見つかりません。init= オプションをカーネルに渡してみてください。トレースを呼び出す：[c782df40] [c0008484] 0xc0008484（信頼できない）[c782df70] [c0025320] 0xc0025320 [c782dfc0] [c0003b78] 0xc0003b78 [c03b78] [c03apxfic1038038478]

しかし、init は /sbin/init の場所にあります。誰でもこれで私を助けることができます。

at91rm9200 プロセッサとat45db642Dデータフラッシュを使用して変更された 2.6.12.1 を実行しているレガシー ボードのファームウェアを、 at45db641Eデータフラッシュを使用するようにアップグレードする作業を行っています。641E の特徴は次のとおりです。

• 32768ページ
• 264バイトのページサイズ
• ページ (264 バイト)、ブロック (2 KB)、セクター (256 KB)、またはチップ全体 (64 M ビット) を消去する柔軟な消去オプション。

カーネル メモリ マネージャーのページ サイズは標準の 4096 バイトだと思います。

適切な jffs2 イメージをデバイスに配置したいと考えています。私が疑問に思っているmkfs.jffs2オプションは次のとおりです (man ページから):

• --pagesize: ページ サイズ SIZE を使用します。デフォルトは 4 KiB です。このサイズは、データ ノードの最大サイズです。ターゲット システムのメモリ管理ページ サイズに従って設定します (注: これは NAND ページ サイズとは関係ありません)。
• --eraseblock: 消去ブロック サイズ SIZE を使用します。デフォルトは 64 KiB です。ターゲット MTD デバイスの消去ブロック サイズとは異なる消去ブロック サイズを使用すると、JFFS2 が最適に実行されない場合があります。指定された SIZE が 4096 未満の場合、単位は KiB と見なされます。

男性は、ページサイズはカーネルメモリ管理ページサイズ（私の場合はデフォルトと同じ4096）に関連しており、デバイスの264バイトのページではないと述べています。--pagesize=4096 を指定する必要がありますが、--pagesize=264 ではありません。これは正しいですか?

--eraseblock は、MTD デバイスの消去ブロックと同じサイズでなければならないとも述べています。私はいくつかのことについて混乱しています。

1. 641E には、いくつかの異なる消去オプションがあります。mkfs.jffs2 --eraseblock オプションにはどれを選択する必要がありますか?
2. 正しいオプションが 641E のページ サイズまたはブロック サイズのいずれかである場合、4096 未満の値はバイト単位ではなく KB 単位であると想定されるという事実を考慮して、mkfs.jffs2 にどのように指定できますか?
3. このリンク(この関連する不十分な SO の質問で参照) は、jffs2 ノードが消去ブロック内に完全に収まる必要があることを示しています。それらのサイズは 4+ KB であり、デバイスの「消去ブロック」サイズよりも大きいため、リンクには「いくつかの erasblock を 64 または 128 KiB の 1 つの仮想消去ブロックに結合して使用する必要があります。これはより最適です」と続きます。 「ドライバーに 128KiB の消去ブロック サイズを報告させ、それをエミュレートする必要があります。そうすれば動作します。そのままでは動作しません。」このような「仮想消去ブロック」を設定するにはどうすればよいですか?
4. at91 データフラッシュ ドライバー内では、device->erasesize=pagesize. そのため、名前は似ているが異なる概念がいくつかあるようです: ドライバー消去サイズ、デバイス消去ブロック サイズ、および jffs2 消去ブロック サイズ。これらの関係と違いは何ですか？jffs2 で指定された消去ブロックのサイズは、ドライバーによって実行される操作に最終的にどのように影響しますか?

助けてくれてありがとう。

jffs2 rootfsをマウントしようとしています。fs がマウントされると、次の警告が表示されます。

ramfsを rootfs として使用し、jffs2 rootfs を手動でマウントした場合、この警告は発生しませんでした。

この警告は、jffs2がノードを古いものとしてマークしようとしたときに発生します。他の意味では、fs は操作可能に見え、ファイルを作成したりファイルを削除したりできます。とにかく、警告が頻繁に表示され、それに悩まされることは別として、最終的にはfsの破損につながるのではないかと心配しています。

パーティション サイズを 0x450000 に減らすと、この警告はなくなりましたが、/etc/dropbear 用の十分なスペースがなく、十分なスペースがあり、適切な場所がない「スイート スポット」を見つけることができませんでした。警告。

さまざまなサイズのパディングを試し、パディングを完全に削除しましたが、役に立ちませんでした。

さまざまな構成でいくつかの rootfs.jffs2 イメージを作成しましたが、問題を解決するものはありませんでした。

rootfs.jffs2 イメージ、空のjffs2パーティション、および作成された /dev/mtdblock3 の 16 進ダンプを調べましたが、異常なことは何も見つかりませんでした。