39個の削除ブロック（= 4.9MiB）を持つmtdパーティションでubifフォーマットを試みました。予約されたブロックが可能な最小のブロック1に減ると（これは悪いことがわかります）、結果ファイルシステムには圧縮されていないデータのための2.2Mの空き容量があります。これは、スペースの45％のみがデータに使用できることを意味します。
jffs2でフォーマットされた同じ領域を使用すると、4.6 MBのデータを書き込むことができました。これはubifs設定サイズの93％以上です。
問題は、64バイトのOOBサイズが次のBCH8およびJFFS2 OBBデータに十分なスペースを提供しないため、jffs2を使用できないことです。TI警告。
FAQの章を読んだ。 私のUBIFSボリュームの容量がクラスJFFS2ボリュームよりはるかに少ないのはなぜですか？ そして dfが空き容量を少なすぎると報告するのはなぜですか？ しかし、まだその費用がどれくらいになるのか信じられません。
（書き込み可能）ubifsボリュームで利用可能なスペースを増やすためにできることはありますか？
ubi0とubi1をマージするとスペースが節約されますか？ （予約ブロックよりも多いですか？）
これは私の設定です。
$ mtdinfo -a
mtd10
Name: NAND.userdata
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 39 (5111808 bytes, 4.9 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:20
Bad blocks are allowed: true
Device is writable: true
$ ubinfo -a
ubi1
Volumes count: 1
Logical eraseblock size: 129024 bytes, 126.0 KiB
Total amount of logical eraseblocks: 39 (5031936 bytes, 4.8 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 1
Current maximum erase counter value: 2
Minimum input/output unit size: 2048 bytes
Character device major/minor: 249:0
Present volumes: 0
Volume ID: 0 (on ubi1)
Type: dynamic
Alignment: 1
Size: 34 LEBs (4386816 bytes, 4.2 MiB)
State: OK
Name: userdata
Character device major/minor: 249:1
dmesg:
[ 1.340937] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
[ 1.347903] nand: Micron MT29F1G08ABADAH4
[ 1.352108] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 1.359782] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
uname -a:
Linux 4.1.18-g543c284-dirty #3 PREEMPT Mon Jun 27 17:02:46 CEST 2016 armv7l GNU/Linux
ubifの生成とテスト：
# flash_erase /dev/mtd10 0 0
Erasing 128 Kibyte @ 4c0000 -- 100 % complete
# ubiformat /dev/mtd10 -s 512 -O 512
ubiformat: mtd10 (nand), size 5111808 bytes (4.9 MiB), 39 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 38 -- 100 % complete
ubiformat: 39 eraseblocks are supposedly empty
ubiformat: formatting eraseblock 38 -- 100 % complete
# ubiattach -d1 -m10 -b 1
UBI device number 1, total 39 LEBs (5031936 bytes, 4.8 MiB), available 34 LEBs (4386816 bytes, 4.2 MiB), LEB size 129024 bytes (126.0 KiB)
# ubimkvol /dev/ubi1 -N userdata -m
Set volume size to 4386816
Volume ID 0, size 34 LEBs (4386816 bytes, 4.2 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "userdata", alignment 1
# mount -t ubifs ubi1:userdata /tmp/1
# df -h /tmp/1
Filesystem Size Used Avail Use% Mounted on
- 2.1M 20K 2.0M 2% /tmp/1
# dd if=/dev/urandom of=/tmp/1/bigfile bs=4096
dd: error writing '/tmp/1/bigfile': No space left on device
550+0 records in
549+0 records out
2248704 bytes (2.2 MB) copied, 1.66865 s, 1.3 MB/s
# ls -l /tmp/1/bigfile
-rw-r--r-- 1 root root 2248704 Jan 1 00:07 /tmp/1/bigfile
# sync
# df -h /tmp/1
Filesystem Size Used Avail Use% Mounted on
- 2.1M 2.1M 0 100% /tmp/1
jffs2を作成してテストします。
# mkdir /tmp/empty.d
# mkfs.jffs2 -s 2048 -r /tmp/empty.d -o /tmp/empty.jffs2
# flash_erase /dev/mtd10 0 0
Erasing 128 Kibyte @ 4c0000 -- 100 % complete
# nandwrite /dev/mtd10 /tmp/empty.jffs2
Writing data to block 0 at offset 0x0
# mount -t jffs2 /dev/mtdblock10 /tmp/1
# df -h /tmp/1
Filesystem Size Used Avail Use% Mounted on
- 4.9M 384K 4.5M 8% /tmp/1
# dd if=/dev/urandom of=/tmp/1/bigfile bs=4096
dd: error writing '/tmp/1/bigfile': No space left on device
1129+0 records in
1128+0 records out
4620288 bytes (4.6 MB) copied, 4.54715 s, 1.0 MB/s
# ls -l /tmp/1/bigfile
-rw-r--r-- 1 root root 4620288 Jan 1 00:20 /tmp/1/bigfile
# sync
# df -h /tmp/1
Filesystem Size Used Avail Use% Mounted on
- 4.9M 4.9M 0 100% /tmp/1
修正する:
いくつかの品質測定を行った結果、下のグラフが表示されました。
これで私の質問をより具体的に説明できます。
この「公式」は次のとおりです。usable_size_mb = (raw_size_mb - 2.3831) * 0.89423077
つまり、私のmtdがどんなに大きくてもボリュームがどんなに大きくても、常に2.38MBを失います。これは19個の削除ブロックサイズです。。残りはユーザーデータの10.6％ファイルシステムオーバーヘッドですが、これは高い値ですが、ubifの場合は予期しないものではありません。
ところで。テスト中に少なくとも17の削除ブロック（= 2.176 MB）が必要であるというカーネル警告が表示されます。しかし、テストに成功した最小のmtdは22ブロック（2.816MB）でした。
答え1
数値が一致しない理由
「最小17個の消去ブロック」警告は、UBIFSファイルシステム自体に必要なブロック数を計算します。 17個の削除ブロックのうち、14個はUBIFSオーバーヘッド、3個は空きファイルシステムスペースです。下の基本 UBI レイヤも 5 つの削除ブロックのオーバーヘッドを使用します。
より多くのスペースを確保する
単一のUBIパーティションと単一のUBIFSファイルシステムがより少ないオーバーヘッドを使用するようにする方法はありません。
ただし、同じMTDデバイスに複数のUBIパーティションがある場合は、マージすることをお勧めします。 UBIは必要に応じて物理的な削除ブロックを論理的な削除ブロックにマッピングするためのより多くのオプションを持っているため、5つの削除ブロックを確保できるだけでなく、摩耗平準化と不良ブロック処理も向上します。
（オーバーヘッドを無視して、それぞれが2つのブロックを持つ2つのパーティションを想像してみてください。そのうちの1つは不良です。パーティションには1つのブロックしかありません。ウェアレベリングは不可能です。必要に応じて2つのファイルシステム間で共有するブロック）。
2 つの隣接する UBI パーティションをマージします。
- MTDパーティションテーブルを更新して、2つのパーティションを1つのより大きなパーティションに置き換えます。
ubiformat大きなパーティションで実行してください。- を使用するか、手動で指定して
ubimkvol適切なパーティション名とサイズを指定して2回実行します。-s-S
UBI+UBIFS間接費会計
まず、UBIレイヤは5つの削除ブロックオーバーヘッドを占めます。
- 2 はボリュームテーブルです。
- 1つはウェアレベリングアルゴリズム用に予約されています。
- 1 論理削除ブロックの安定した内部更新を可能にする「Atomic LEB Change」機能用に予約
- 1（理想的にはそれ以上）は、誤った物理削除ブロックを処理するために予約されています。
次に、UBIFSレイヤには、ファイルシステムメタデータの最小削除ブロック数があります。
- 1は、ボリュームを有効なUBIFSとして識別し、ファイルシステムパラメータを格納するファイルシステムスーパーブロックを表します。
- 2はマスターノード領域（重複コピー）であり、ファイルシステム検索に使用されるツリーのルートです。
- ログ領域は2つ以上（空き領域で計算）
- 2は、各論理削除ブロックの使用方法を追跡するLEB属性ツリーです。
- 孤児ゾーンの場合、1つ以上
- 8ファイルシステムメタデータ用に予約済み（ガベージコレクション、削除、芽、インデックス）
- ログにないコミットされたデータ（空き領域）に対して少なくとも1つ。
引用する
UBIオーバーヘッドの場合、linux-mtdサイトには簡単な説明。
UBIFSオーバーヘッドのために、より多くの掘削作業を行う必要があります。これmtd-utilsのソースコード削除ブロックの絶対最小数を計算し、各ブロックの目的について言及します。その意味を理解するためには、UBIFSホワイトペーパーとても便利です。