LFSについてわかっていることなど。
LFSはログ構造化ファイルシステムという名前のとおり、 ほぼすべてのデータをログとしてストレージに書き出します。 ほぼ、なのは起動時チェックポイントのための情報だけは固定位置に書かざるを得ないからです。 ZFSも同様のアプローチを採っています。 ログ構造だからといってNANDフラッシュにそのまま書けるわけではありません。
LFSでは書き込まれるデータはログになり、ログは無限に書き続けなければなりません。 そこで古くなったログを削除して、領域として回収する再利用を行います。 この回収単位をセグメントと呼びます。 NetBSD LFSのセグメントの標準サイズは1MBです。
ほぼすべてがログに書かれているので、 最後に書いた領域だけを検査すればファイルシステムの整合性が保たれるという特徴があります。 ストレージへの書き込みがセグメント一括で行われるのでシークが少なく、その分のIOPSを他の用途に回せます。 ただし実際には過剰なメモリバッファが災いして読み書きがカクカクすることが多く、 I/O遅延時間のQoS管理が実装上の課題になると考えています。 読み出しが散らばって遅いという問題はメモリバッファで解決するという設計思想です。
情報がログに書かれるというものの性質上、 固定されたinode領域を持っていません。 必要に応じて割り当てられ、要らなくなれば解放される構造が採用されています。 FFSv1やFFSv2で悩ましい設計であったところの「総inode数」を事前に考える必要がありません。
mount/umountを繰り返すとメタデータが壊れます。 これを致命的と考えるかどうか用途によりますが、 一般的な解釈としては致命的でしょう。
そのほか最低限の動作はするように見えます。 読み書きはできるものの、データ保存には使えません。 通常のファイルシステムとして使うにはQoLが悪すぎるというのが現状の評価です。 一度書いたらあまり読まないけども、 再起動後に読み返すかもしれない /var/tmp や tooldir, objdir に使うのが妥当な用途でしょう。 ですが、実際そこまで細かくパーティションを作らないと思います。
LFSでは2TBを超えるパーティションはまだサポートされません。 1TB以上2TB未満であればnewfs_lfsがLFS64を試みてくれますが、 それをマウントしようとしてみると正常に動作しないように見えます。 たとえば約8TBのパーティションを初期化しようとしてnewfs_lfsを実行すると、 newfs_lfsが落ちます。 これは64bit APIが出揃っていないためと考えられます。 LFS32を動かすことが優先されるでしょうから、 LFS64に手が回るのはまだ先のことでしょう。
それではLFS32が動くかというとまだ動きません。 ディスクの空き容量の会計をしている部分がなかなかの鬼門なのであるらしく、 その部分がまともに動かないのです。 コードを読む限りにおいてはメンテナも半ば匙を投げているのではないかという雰囲気さえあります。 今後メンテナがどのような対応をするのかは不明です。