「Breaking Apart the VFS for Managing File Systems」という USENIX HotStorage 2018 で発表された論文を読みました。これはそのメモ書きです。

免責 精読しておらず内容が間違っている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue へお願いします。

読書状況

ざっくり全体を流し読み。

概要

VFS はファイルシステムの管理ツールのための API を提供していない。ファイルシステムのフォーマットはそれぞれ異なるため、ツールの作者はファイルシステム毎にそのメタデータや内部オブジェクトを直接触るツールを書く必要があった。本論文ではツール用の API を実装した extended VFS (eVFS) を提案し、その利用例としてファイルシステムの変換ツールを実装し評価している。

利点

  • ファイルシステム毎にツールを書く必要がなくなるため、先進的・実験的なファイルシステムでも eVFS のインタフェースを実装すればすぐにツールが使えるようになる。
  • ファイルシステムのメタデータを直接触る必要がなくなるため、ロバストなツールが書ける。

アプローチ

  • ファイルシステムに依存しない 4 種類のオブジェクトを定義
    • files or directories, blocks or extents, directory entries, file-system wide settings (block size, file system size, label)
    • なぜこれらオブジェクトをインタフェース定義したのか、そのユースケースとあわせて論文内で説明されている。
  • 各ファイルシステムで eVFS のインタフェースを実装
    • 本研究では extent-based Ext4 file system と log-structured F2FS file system に実装。
  • ファイルシステムの変換ツールを実装して評価
    • Ext4 から F2FS へ変換。
    • オフラインでのみ利用できる（アンマウント状態で排他的にアクセスできる）。
    • 可能であればファイルシステムを in-place で変換する。メタデータを書き換えるだけで、データのコピーをしないので高速。既存ツールでもあるが、実装が困難で一般的ではないらしい。
  • ユーザランドでのジャーナリング手法を色々工夫
    • （この辺りはちゃんと読んでない・・・）

評価

  • 筆者達が以前実装したファイルシステムの変換ツール（Spiffy converter）と比較。以前のツールよりファイルシステム依存のコード行が少なく済み、かつ他のファイルシステムにも使いまわししやすいツールができた。
  • ジャーナリングの on/off で比較。20% ほどのオーバヘッドとのこと。

関連研究

  • 色々ある
    • ファイルシステム特有のコードの量
    • 一貫性モデルの違い

制限と今後の課題

  • 扱うファイルシステムのメタデータの構造によっては特別なサポートが必要になる（例えば Ext4 は extents から inodes へのマップがないので云々）
  • 物理的なデータチャンクに直接アクセスできない。
  • 現在はオフラインでしか使えないツールだが、そのうちオンラインでも使えるようにしたい。そのためのトランザクションサポートが必要。

疑問・感想

  • 抽象化インタフェースを拡張して汎用的なツールを書きやすくするというのはわりと一般的な手法だと思うんだけど、VFS ほど有名なインタフェースでそれが行われていなかったことに驚いた。Linux の開発コミュニティ側でそういう動きはなかったのかな？