小さなubifsボリュームを作成するときの驚くほど大きなオーバーヘッド
39個の消去ブロック（= 4.9 MiB）を持つmtdパーティションで、ubifsをフォーマットしようとしました。結果として得られるファイルシステムには、予約済みブロックが可能な最小の1ブロックに削減されたときに、220万の非圧縮データの空き領域があります（これは良くないことを知っています）。これは、スペースの45％のみがデータに使用できることを意味します。
Jffs2でフォーマットされた同じ領域により、4.6 MBのデータを書き込むことができます。これは、ubifsセットアップの93％以上のサイズです。
問題は、 TI警告 で説明されているように、64バイトのOOBサイズではBCH8とJFFS2の両方のOBBデータに十分なスペースが提供されないため、jffs2を使用できないことです。
すでにFAQの章を読みました BIFSボリュームの容量が同等の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
_ubifsの作成とテスト：
_# 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％のファイルシステムオーバーヘッドです。これは高い値ですが、ubifsにとっては予期しないことではありません。
ところで。テストを実行すると、少なくとも17個の消去ブロックが必要であるというカーネル警告が表示されました（= 2.176MB）。しかし、テストを正常に実行した最小のmtdには22ブロック（2.816 MB）がありました。
数字が一致しない理由
「少なくとも17個の消去ブロック」警告は、UBIFSファイルシステム自体に必要なブロックをカウントします。これらの17個の消去ブロックのうち、14個はUBIFSオーバーヘッドであり、3個は使用可能なファイルシステムスペースです。下にあるUBIレイヤーも、5つの消去ブロックのオーバーヘッドを使用します。
より多くのスペースを取得する
単一のUBIFSファイルシステムで単一のUBIパーティションを使用するオーバーヘッドを少なくする方法はありません。
ただし、同じMTDデバイスに複数のUBIパーティションがある場合は、それらをマージすることをお勧めします。 5つの消去ブロックが解放されるだけでなく、UBIには必要に応じて物理消去ブロックを論理消去ブロックにマッピングするためのより多くのオプションがあるため、ウェアレベリングと不良ブロック処理が改善されます。
（オーバーヘッドを無視して、それぞれ2つのブロックの2つのパーティションを想像してください。そのうちの1つは不良です。現在、1つのパーティションには1つのブロックしか残っておらず、ウェアレベリングを実行することはできません。しかし、2つをマージすると、3つの良好なブロックが残ります。必要に応じて、2つのファイルシステム間で共有します。）
2つの隣接するUBIパーティションをマージするには：
- MTDパーティションテーブルを更新し、2つのパーティションを1つの大きなパーティションに置き換えます。
- その1つの大きなパーティションで
ubiformatを実行します。 ubimkvolを2回実行し、適切なパーティション名を指定し、-sまたは-Sを使用してサイズを手動で指定します。
UBI + UBIFSオーバーヘッドのアカウンティング
まず、UBIレイヤーは5つの消去ブロックのオーバーヘッドを取ります。
- ボリュームテーブルの場合は2
- 1はウェアレベリングアルゴリズム用に予約されています
- 1は、論理消去ブロックの信頼性の高いインプレース更新を可能にする「アトミックLEB変更」機能用に予約されています
- 1（理想的にはあなたが言ったようにもっと）は悪い物理的消去ブロックを処理するために予約されています。
次に、UBIFSレイヤーには、ファイルシステムメタデータ用の最小数の消去ブロックがあります。
- ボリュームを有効なUBIFSとして識別し、ファイルシステムパラメータを格納するファイルシステムスーパーブロックの場合は1
- ファイルシステムルックアップに使用されるツリーのルートであるマスターノード領域（冗長コピー）の場合は2
- ログ領域が2以上（使用可能スペースにカウントされます）
- 各論理消去ブロックがどのように使用されるかを追跡するLEBプロパティツリーの場合は2
- 孤立領域の場合は1つ以上（削除されたファイルを追跡するため、アンクリーンアンマウント後に正しくクリーンアップされます）
- 8ファイルシステムメタデータ（ガベージコレクション、削除、つぼみ、インデックス）用に予約済み
- ログ（使用可能スペース）にないコミット済みデータの場合は1以上。
参考文献
UBIオーバーヘッドの場合、linux-mtdサイトには 簡単な説明 があります。
UBIFSのオーバーヘッドについては、もう少し掘り下げる必要がありました。 mtd-utilsのソースコード は、消去ブロックの絶対最小数をカウントアップし、各ブロックの目的を示します。それを理解するには、 BIFSホワイトペーパー が役立ちます。