FFS: Berkeley fast filesystem

Options

FFSにはマウントオプションとして、 デフォルト動作のほかにlogとdiscardがあります。

• 何も付けないデフォルトでは、従来通りの古典的な動作をします。 メタデータはfsckできると期待される程度に同期的に扱われます。 ユーザデータは非同期的に扱われます。 クラッシュした場合はfsckを走らせなければなりません。
• logオプションは、WAPBLを使って、メタデータジャーナリングを行います。 メタデータを一度ジャーナルに書くことで、 不意のクラッシュでもfsckの利用頻度を減らす効果があります。 WAPBLではメタデータを一度ジャーナルに書いてから本来の位置に書きます。 メタデータを二度書くことになってしまうため、その分だけIOPSを余分に消費します。 つまり、ジャーナリングを使うと書き込みが遅くなります。 加えて、logオプションで有効化されるWAPBLにはメタデータを書けるサイズに上限があります。 上限を超えると、カーネルがパニックします。 一定サイズ以上のファイルを削除することができなくなります。
• discardオプションは、TRIMを発行することを指示します。 NetBSDにはLinuxでおなじみのfstrimはまだありません。 このオプションによってしか、UNMAP/TRIMを発行する良い方法はないようです。
• syncオプションはメタデータとユーザデータの双方を同期的に(順序立てて更新するように)扱います。

logオプションとdiscardオプションを同時に使うことはできず、 排他の利用となります。

WAPBLでは1GBあたり1MBのジャーナル領域を予約し、最大64MBまで確保される、という動作が標準です。 大半の用途は標準の動作で足りることがわかっていますが、 Proxmox VEのバックアップ領域など「巨大なファイルを扱う」場合にジャーナル領域の不足を経験することになります。 30GB前後のファイルの削除操作を64MBのジャーナルには収めきれません。 ジャーナルを扱うトランザクションがファイルの削除操作で非常に巨大になるのは実質的に不具合です。 ただし修正されるめどは立っていないようです。 ジャーナル領域のサイズで右往左往するのは運用上は現実的ではないため、 このような巨大なファイルを扱うエリアはZFSに切り替えてしまうべきでしょう。

ファイルシステム内部に確保したジャーナル領域のサイズを増減する場合は一度ジャーナル領域を削除する必要があります。 tunefs -l 0を実行してゼロにしてからジャーナルなしでマウント、続けてアンマウントします。 これでジャーナル領域が一旦削除されます。 tunefs -l 256M等を実行して所望の値を設定してから、改めてジャーナルありでマウントします。

Versions

FFSv1は32bit inodeを採用したファイルシステムです。 先頭8KBはブートレコード等のために予約されており、ファイルシステムとしては使用されません。 NetBSDではブートレコード部分にMBR+disklabelを収めることができます。

FFSv2は64bit inodeを採用したファイルシステムです。 先頭64KBはブートレコード等のために予約されており、ファイルシステムとしては使用されません。 FFSv2にはACLを実装したバリアントがあります。