ubifsの安全性のために別々のubiボリュームを持つことは理にかなっていますか？
Ubifs以前の時代には、組み込みシステムでは、保護のためにフラッシュにいくつかの（MTD）パーティションをセットアップするのが一般的でした。たとえば、読み取り専用ファイルシステムを含むパーティションは/としてマウントでき、構成データ用の個別の書き込み可能パーティションは/ homeや/ dataなどとしてマウントできます。
一方、UBIの主な機能の1つは、論理的な「UBIボリューム」を提供すると同時に、フラッシュデバイス全体でウェアレベリングを実行することです。 MTD Webサイト からの引用：
UBIは、フラッシュデバイス全体にウェアレベリングを実装します（つまり、UBIボリュームの1つの論理消去ブロックのみを継続的に書き込み/消去できますが、UBIはこれをフラッシュチップのすべての物理消去ブロックに拡散します）。
私の質問は次のとおりです。たとえば、個別のUBIボリュームを用意することは理にかなっていますか。読み取り専用ファイルシステムと構成データ？それとも、フラッシュ全体が内部でウェアレベリングに関与しているため、これは無意味ですか？
はい、それは確かに理にかなっています。組み込みシステムは通常、2つ以上の個別の起動可能なイメージをフラッシュに保持します。このようにして、一方を消去してアップグレードし、アップグレードが失敗した場合にもう一方にフォールバックできます。ルートファイルシステムと構成データを同じボリュームに保持している場合、構成データを新しいボリュームに移動することを管理する必要があるため、アップグレードプロセスが非常に複雑になります（そして、どのデータが「さまざまな障害/フォールバックの場合に「正しい」）。
したがって、静的プログラムデータを可変構成データとは別のボリュームに保持することは、一般的には良い考えです。特にUBIFSを考慮すると、いくつかのオプションがあります。
- Rootfsを生のUBIボリュームの上にあるsquashfsに保持します。 MTD_UBI_BLOCKカーネルオプションを使用して、UBIボリュームをブロックデバイスとして提示し、そこからスカッシュフをマウントできます。この場合、U-Bootは未加工のUBIボリュームを書き込むことができますが、UBIFS上のファイルしか読み取ることができないため、U-Bootから直接新しいイメージを書き込む可能性があります。
- Rootfsを個別のUBIFSとして保持します。 UBIFSはファイルシステムメタデータの格納においてsquashfsよりもはるかに効率が低く、rootfsが読み取り専用の場合、実際のメリットはないため、これには多くの余分なスペースが必要です。
- RootfsをsquashfsファイルとしてUBIFSボリュームに保持し、ループマウントします。これは少し余分なスペース（rootfsファイル自体のメタデータ）を使用しますが、ブートイメージと構成データ用に予約するスペースの量を心配する必要がないため、柔軟性があります。 （ただし、ブートイメージのすべてのスペースを誤って使い果たした場合、この柔軟性は悪いことになる可能性があります。）
- RootfsをMTDに直接保持します。これにより、rootfsのウェアレベリングの利点が完全に失われ、回転できる消去ブロックが少なくなるため、書き込み可能なボリュームのウェアレベリングの効果が低下します。