Ubifs以前の時代には、組み込みシステムでは、保護のためにフラッシュにいくつかの(MTD)パーティションをセットアップするのが一般的でした。たとえば、読み取り専用ファイルシステムを含むパーティションは/としてマウントでき、構成データ用の個別の書き込み可能パーティションは/ homeや/ dataなどとしてマウントできます。
一方、UBIの主な機能の1つは、論理的な「UBIボリューム」を提供すると同時に、フラッシュデバイス全体でウェアレベリングを実行することです。 MTD Webサイト からの引用:
UBIは、フラッシュデバイス全体にウェアレベリングを実装します(つまり、UBIボリュームの1つの論理消去ブロックのみを継続的に書き込み/消去できますが、UBIはこれをフラッシュチップのすべての物理消去ブロックに拡散します)。
私の質問は次のとおりです。たとえば、個別のUBIボリュームを用意することは理にかなっていますか。読み取り専用ファイルシステムと構成データ?それとも、フラッシュ全体が内部でウェアレベリングに関与しているため、これは無意味ですか?
はい、それは確かに理にかなっています。組み込みシステムは通常、2つ以上の個別の起動可能なイメージをフラッシュに保持します。このようにして、一方を消去してアップグレードし、アップグレードが失敗した場合にもう一方にフォールバックできます。ルートファイルシステムと構成データを同じボリュームに保持している場合、構成データを新しいボリュームに移動することを管理する必要があるため、アップグレードプロセスが非常に複雑になります(そして、どのデータが「さまざまな障害/フォールバックの場合に「正しい」)。
したがって、静的プログラムデータを可変構成データとは別のボリュームに保持することは、一般的には良い考えです。特にUBIFSを考慮すると、いくつかのオプションがあります。