LFSについてわかっていることなど。
LFSはログ構造化ファイルシステムという名前のとおり、 ほぼすべてのデータをログとしてストレージに書き出します。 ほぼ、なのは起動時チェックポイントのための情報だけは固定位置に書かざるを得ないからです。 ZFSも同様のアプローチを採っています。 ログ構造だからといってNANDフラッシュにそのまま書けるわけではありません。
LFSでは書き込まれるデータはログになり、ログは無限に書き続けなければなりません。 そこで古くなったログを削除して、領域として回収する再利用を行います。 この回収単位をセグメントと呼びます。 NetBSD LFSのセグメントの標準サイズは1MBです。
ほぼすべてがログに書かれているので、 最後に書いた領域だけを検査すればファイルシステムの整合性が保たれるという特徴があります。 ストレージへの書き込みがセグメント一括で行われるのでシークが少なく、その分のIOPSを他の用途に回せます。 ただし実際には過剰なメモリバッファが災いして読み書きがカクカクすることが多く、 I/O遅延時間のQoS管理が実装上の課題になると考えています。 読み出しが散らばって遅いという問題はメモリバッファで解決するという設計思想です。
情報がログに書かれるというものの性質上、 固定されたinode領域を持っていません。 必要に応じて割り当てられ、要らなくなれば解放される構造が採用されています。 FFSv1やFFSv2で悩ましい設計であったところの「総inode数」を事前に考える必要がありません。
最低限動作はするように見えます。 通常のファイルシステムとして使うにはQoLが悪すぎるというのが現状の評価です。 一度書いたらあまり読まないけども、 再起動後に読み返すかもしれない /var/tmp や tooldir, objdir に使うのが妥当な用途でしょう。 ですが、実際そこまで細かくパーティションを作らないと思います。
ログ構造の都合でNFSエクスポートすると便利に使えそうに見えます。 実際にはまともに動きません。 内部的な同期またはcleanerとの協調にかかる動作が重すぎるようです。
LFSにはバージョン1とバージョン2があり、現在使われている(?)ものはバージョン2です。 バージョン2には32bit inodeを使うLFS32と、64bit inodeを使うLFS64があります。 LFS64ではブロックポインタ等が64bitに拡大されており、 2TB以上のパーティションを扱えることを狙ったバリアントと位置づけられます。 歴史的な事情からLFS32の実装が完了していない実験的な段階のため、 その拡張バリアントであるLFS64についても実験的であり、 ディスク形式の互換性が将来に向かって保たれる保証はありません。
2026年に行われたコミットでfcntl()を使っているクリーニングAPIが差し替えられ、 カーネル内で多くの部分が動作するようになりました。 このあたりのカーネルとユーザランドの組み合わせでは、 LFS32がそこそこ動くようです。
セグメントを一度書いたら終わりというステータスは脱却したように見えます。 末尾から先頭に戻ってセグメントを巡回して書けるようになったらしい、 という辺りがポイントです。 2025年までは、ファイルシステムにあるセグメントを一度書いたらそこでほぼおしまいでした。
LFSでは2TBを超えるパーティションはまだサポートされません。 1TB以上2TB未満であればnewfs_lfsがLFS64を試みてくれますが、 それをマウントしようとしてみると正常に動作しないように見えます。 たとえば約8TBのパーティションを初期化しようとしてnewfs_lfsを実行すると、 newfs_lfsが落ちます。 これは64bit APIが出揃っていないためと考えられます。 LFS32を動かすことが優先されるでしょうから、 LFS64に手が回るのはまだ先のことでしょう。