Huawei が EROFS を最初に Android デバイス用に設計された読み取り専用ファイル システムとして発表してから、すでに 5 年が経過したとは思えませんが、メインラインの Linux カーネルで一般的な Linux ユーザーに役立つことが証明されており、興味深いユースケースも登場しています。コンテナなどの周りに。開発中の Linux 6.4 カーネルでは、この読み取り専用ファイル システムがさらに改善されています。
Linux 6.4 の EROFS は、サブページ ブロック サポートのサポートを取得します。これは、より大きなページがより一般的である可能性がある AArch64 スペースで特に役立ちます。 Linux 6.4 の EROFS は、長い xattr 名プレフィックス機能も追加します。マルチブロブ イメージを仮想マシンに接続するためのフラット化されたブロック デバイスもサポートされています。
既にマージされた Gao Xiang からのプル リクエスト説明:
このサイクルでは、圧縮されていないファイルのサブページ ブロックのサポートが利用可能です。これは主に、arm64 で 16/64k ページのゴールデン 4k ブロック イメージを有効にするために使用されます。さらに、エンド ユーザーはこの機能を使用してマニフェストを作成し、ゴールデン tar データを直接参照することもできます。
さらに、長い xattr 名のプレフィックスのサポートもこのサイクルで導入され、同じプレフィックスを持つ xattr が多すぎるのを回避します (例: overlayfs xattrs)。これは、erofs + overlayfs の組み合わせ (Composefs モデルなど) に役立ちます。画像サイズは ~14% 縮小され、実行時のパフォーマンスもわずかに向上します。
パッチ シリーズ:
overlayfs は xattrs を使用して独自のメタデータを保持します。 Composefs モデル [1] のように、そのような xattr が頻繁に使用される場合、さまざまな xattr 値を持つ大量の xattr が存在しますが、有効な一般的な xattr 名はごくわずかです (trusted.overlay.redirect、trusted.overlay.digest など)。未来）。
…
これを修正するために、長い xattr 名プレフィックスを導入しましょう。これらは、長い xattr 名プレフィックスがユーザー指定であることを除いて、定義済みの名前プレフィックスと同様に機能します。長い xattr 名プレフィックスが使用される場合、共有された長い xattr プレフィックスはパックまたはメタ i ノードに保存されますが、長い xattr 名プレフィックスとは別に、xattr 名の残りの末尾部分は erofs_xattr_entry.e_name に保存されます。 xattr 名が長い xattr 名のプレフィックスと正確に一致する場合、e_name は空です。
