LFSについてわかっていることなど。
LFSはログ構造化ファイルシステムという名前のとおり、 ほぼすべてのデータをログとしてストレージに書き出します。 ほぼ、なのは起動時チェックポイントのための情報だけは固定位置に書かざるを得ないからです。 固定位置に最新状態を指すポインタのテーブルを持つ設計に関しては、 トランザクション志向であるZFSにおいても同様のアプローチが採用されています。 ログ構造だからといってフラッシュメモリにそのまま書けるわけではありません。
LFSでは書き込まれるデータはログになり、ログは無限に書き続けなければなりません。 そこで古くなったログを削除して、領域として回収する再利用を行います。 この回収単位をセグメントと呼びます。 NetBSD LFSのセグメントの標準サイズは1MBです。
ほぼすべてがログに書かれているので、 最後に書いた領域だけを検査すればファイルシステムの整合性が保たれるという設計上のゴールがあります。 ストレージへの書き込みがセグメント一括で行われるのでシークが少なく、その分のIOPSを他の用途に回せます。 読み出しが散らばって遅いという問題はメモリバッファで解決するという設計思想です。
情報がログに書かれるというものの性質上、 固定されたinode領域を持っていません。 FFSv1やFFSv2で悩ましい設計であったところの「総inode数」を事前に考える必要がありません。
LFSはパーティションのサイズとして2TB以下で動作します。 それ以上は意図的に使えないように設計されています。 64bitポインタを使うバージョンは設計途上であり、仕様が固定されていません。 パーティションサイズの相場感としてcurrentのソースコードを展開して作業領域にする用途であれば128GB程度もあれば足ります。 割当ができるパーティション数についてはGPTで解決されました。 ただし大きなボリュームが作れないことは不便ではあるため、 安定化された後のLFSにとってはサイズをスケールできるかどうかが課題になります。
2026年現在現行であるLFS version 2はオンディスクレイアウトとしてUFSの伝統を引きずっています。 つまりフラグメントとブロックの概念は存在しますが、 ブロックはブロック境界に整列されなければなりません。 ログ構造化ファイルシステムとしてデータを詰めて配置することはできません。 データ記録単位はフラグメント単位ですが、 ディスク利用効率の観点から言うとブロックサイズ単位しか意味を持ちません。 512e ハードディスクの利用においては1k frag/4k blockのデフォルト維持が良いと思われます。 正常に動作することが確認できるなら4k frag/4k blockのuniform addressingが良いでしょう。
userland cleanerであればbuild.shを回すことができます。
in-kernel cleanerが有効化され、かつ既定の選択になりました。 コード自体は半年ほど前にコミットされていたものです。
in-kernel cleanerに含まれていたメモリアクセスでオーバーランする問題が、ひとつ修正されました。 このコードはコミットされた時点で既定で使われていたもので、 userland cleanerであっても発動する仕組みになっていました。 今回の修正で潰しきったかどうかはわかりません。
inodeブロックの隙間を通じてカーネルメモリの内容が漏れる問題が修正されました。
inode freelistをsortするロジックの残滓が取り除く取り組みが行われました。 これはifileのデータ構造を壊す原因になっていたものです。 これにより、fsck_lfsで報告されるエラーがひとつ減りました。