ubifが登場する前の組み込みシステムの一般的な慣行は、保護のためにフラッシュメモリに複数（MTD）パーティションを設定することでした。たとえば、読み取り専用ファイルシステムを含むパーティションは/としてマウントでき、構成データ用の別々の書き込み可能パーティションは/homeまたは/dataなどでマウントできます。
一方、UBIの主な特徴の1つは、フラッシュデバイス全体にレベリングを着用しながら、論理的な「UBIボリューム」を提供することです。から引用MTDウェブサイト:
UBIは、フラッシュデバイス全体にわたってウェアレベリングを実装します（つまり、UBIボリュームの1つの論理的な削除ブロックのみを継続的に書き込み/削除できますが、UBIはそれをフラッシュチップのすべての物理的な削除ブロックに拡張します）。
私の質問は：読み取り専用ファイルシステムと構成データなどに別々のUBIボリュームを持つのが合理的ですか？それとも、フラッシュメモリ全体が内部的にウェアレベリングに参加するので、これは意味がないのでしょうか？
ベストアンサー1
はい、確かに言います。組み込みシステムは通常、フラッシュメモリに２つ以上の別個のブータブルイメージを保持する。これにより、1つを消去してアップグレードでき、アップグレードが失敗した場合は別のものに置き換えることができます。ルートファイルシステムと構成データを同じボリュームに保持する場合は、構成データを新しいボリュームに移動することを管理する必要があるため、アップグレードプロセスがより複雑になります（そして、さまざまな障害が発生したときにどのデータが「残っているか」を追跡/修正する必要があります）。 。代替の場合 ')。
したがって、通常、静的プログラムデータと変数構成データを別々のボリュームに保存することをお勧めします。具体的には、UBIFSを考えると、いくつかのオプションがあります。
- 元の UBI ボリュームの上に rootfs を squashfs に保存します。 MTD_UBI_BLOCKカーネルオプションを使用してUBIボリュームをブロックデバイスとして提供し、そこからsquashfsをマウントできます。この場合、U-Bootは元のUBIボリュームに書き込むことができますが、UBIFSのファイルのみを読み取ることができるため、U-Bootから直接新しいイメージを書き込むことができます。
- rootfsを別々のUBIFSにしてください。 UBIFSは、ファイルシステムのメタデータを保存するときにsquashfsよりも効率がはるかに低く、rootfsが読み取り専用の場合は実質的な利点がないため、多くの追加スペースが必要です。
- UBIFSボリュームにrootfsをsquashfsファイルとして保持し、ループにマウントします。これは少し余分なスペース（rootfsファイル自体のメタデータ）を使用しますが、ブートイメージと設定データのために予約するスペースを心配する必要がないため、柔軟性が高くなります。 （ただし、誤ってブートイメージのすべてのスペースを使用している場合は、この柔軟性は悪い可能性があります。）
- MTDに直接rootfsを残してください。これは、rootfsの摩耗平準化の利点を完全に失い、リサイクルするための削除ブロックが少ないため、書き込み可能ボリュームに対する摩耗平準化の効率を低下させます。