PythonでFUSEファイルシステムを書くガイドが始動

 (gwolf.org)
1 ポイント 投稿者 GN⁺ 2024-10-13 | 1件のコメント | WhatsAppで共有
  • 授業用ファイルシステムのプロジェクトとChiPy発表の準備が重なり、PythonでFUSEベースのファイルシステムを段階的に作るGitLabガイドが始まった
  • 授業で使うFIUnamFSは、連続ファイル割り当て、サブディレクトリ非対応、1.44MBフロッピーディスク相当の容量制限を持つおもちゃのファイルシステムである
  • 6学期間にわたり各学期30〜40人の学生に課題を出してきたが、FUSE実装を提出したのは1人だけで、追従しやすいPython FUSE教材の必要性が高まっていた
  • 新しいガイドは空のファイルシステムから始めてシステムコールと機能を追加していく段階的課題形式で、RAMベースの読み書きや読み取り専用パススルー実装まで扱う
  • DNS、Markdownのオンザフライ変換、unzip、コメント除去ファイルシステムといった短い例も併載され、学生が実用的な例でFUSEを学べる

授業プロジェクトから始まったPython FUSEガイド

  • DebConf22でChicago Python User Group向けの発表提案を受けた後、DebConf24で再び話が出て、Python発表のテーマを探すことになった
  • Pythonを主力言語と考えているわけではないが、学生が最もよくついてこられる言語なので、授業ではPythonを使っている
  • 授業プロジェクトの FIUnamFS は、「Facultad de Ingeniería, Universidad Nacional Autónoma de México」の略で、メキシコ国立自治大学工学部の授業で使われているファイルシステムである
    • 連続ファイル割り当てベースである
    • サブディレクトリをサポートしない
    • 通常は1.44MBフロッピーディスク相当の容量に制限される
    • 仕様と実装が簡単なおもちゃのファイルシステムとして使われている
  • 単純なメニューよりも洗練されたインターフェースを作るよう学生に求めてきており、ユーザーが意識せずにFIUnamFSを使うにはFUSEが適していると考えた
  • このプロジェクトを6学期間、各学期30〜40人に課してきたが、実際にFUSE実装を提出した学生は1人だけだった

既存資料の限界と選択肢

GitLabガイドの構成

発表日程と公開資料

関連記事

1件のコメント

 
GN⁺ 2024-10-13
Hacker News のコメント

  • libfuse GitHub の [0] には、C/C++ 向けのサンプルが複雑さ別にうまく整理されている
    passthrough.c は既存のファイルシステムをミラーリングするが、「性能がひどい」とされており、passthrough_fh.c は「そこまで悪くはない」とのこと
    passthrough_ll.c は低レベル API で実装されており、「3つの中ではいちばんマシ」とされ、passthrough_hp.cc は C++ で書かれた高性能版である
    メモしておいた興味深い FUSE プロジェクトとしては、大容量ファイルの分割 [1]、ZFS 増分スナップショットをファイルとして表示 [2]、透過的ファイルシステム圧縮 [3]、アーカイブをファイルシステムとしてマウントする選択肢 [4]、[5] がある
    [0] https://github.com/libfuse/libfuse/tree/master/example
    [1] https://github.com/seiferma/splitviewfuse
    [2] https://github.com/UNFmontreal/zfs_fuse_snapshot
    [3] https://github.com/FS-make-simple/fusecompress
    [4] https://github.com/google/fuse-archive
    [5] https://github.com/mxmlnkn/ratarmount

    • [2] は良いコード例にはなるかもしれないが、この機能はすでに ZFS に内蔵されている
      すべてのデータセットのマウントポイントには、ls -A にも表示されない隠し .zfs フォルダがあり、存在すると信じて直接 cd すればよい
      その下に snapshot フォルダがあり、その中にそのデータセットの各スナップショット用フォルダがあり、スナップショット内のファイルが入っている
      たとえば zrepl_20241011_010143_000 スナップショットの /etc/hosts は /.zfs/snapshot/zrepl_20241011_010143_000/etc/hosts にある
      この魔法のような隠し動作が気に入らないなら、zfs set snapdir=visible で通常のフォルダのように見える設定にもできる
    • 少し前に Linux で 大文字小文字の区別を回避する用途として FUSE を考えていた
      関連リンクはありがたく、勘が少し鈍っているので、役に立った FUSE チュートリアルやガイドがあれば教えてほしい

  • FUSE は好きだが唯一の選択肢ではなく、この前 9p プロトコルで仮想ファイルシステムを実装してみたらかなり面白かった
    記憶では py9p を使い、Python での体験は fuse-python よりずっと良かった
    必要なら 9pfuse で 9p サービスを FUSE 経由でマウントできるが、自分はカーネルの v9fs クライアントを使った
    単にネットワーク越しにファイルシステムを提供したいだけなら diod 9p サーバーを使った気がするし、全体として見て回る価値のある小さなエコシステムだ

    • 9p は本当に優れた小さなプロトコルで、diod[0] にはプロトコル自体の文書もかなりあり、内容もシンプルだ
      自分のメモは [1] にあるが、ほとんどは原典資料へのリンク集である
      FUSE も良いが、9P はより汎用的で、Windows を含めたさまざまな場所に品質の高い実装がある
      ただし 9p の性能特性については確信がなく、遅いという話を見たことはあるが、決定的な資料は見つけられていない
      ベンチマークや情報があるのか気になる
      [0]: https://github.com/chaos/diod/blob/master/protocol.md
      [1]: https://athenaeum.wiki/Zettelkasten/9p
    • 18か月ほど前に HTTPS URL の前に FUSE を置く実験をした
      大きなファイルを先にダウンロードせず、ローカルファイルのようにランダムリードしたかった
      苦労のひとつは、FUSE のブロックサイズが小さすぎて、バックエンドへの HTTP 呼び出しの遅延や churn が大きくなり、かなり複雑なキャッシュ／先読みロジックが必要になったことだ
      カーネルの先読みロジックはまったく機能していないように見え、当時は誘導する方法を見つけられなかった以外、深くは調べなかった
    • qemu では 9p(virtio-9p) より fuse(virtiofs) を使ったほうが性能が良い場合がある
      FAQ は https://virtio-fs.gitlab.io で見られる
    • py9p は最後のリリースが 2013 年で、まだ「beta」と表示されているようだ
      それでもすばらしいプロジェクトだ

  • ちょうど1か月前にまったく同じ手順を踏む必要があったとき、これを知っていればよかったと思う
    Jiraを少しでも扱いやすくしようとする切実な試みとして、内部の課題分類を使ってツリーを作る jira-as-filesystem プロジェクトを思いついた
    ディレクトリは課題を、ファイルは課題フィールドを、サブディレクトリは関連する課題を表すようにして、最終的に fuse-python を選んだ
    しばらく作業できていないが、すでに抽象化の段階で問題が起きていた
    ディレクトリ名を課題 ID だけにすると自動化はしやすいが、ls すると判別しづらい ID ばかりが並んで人間にはたどりにくいため、課題 ID の後ろに slug 化した要約を付ける並列の -with-summary ディレクトリ型を追加した

    • 良いアイデアだという意味ではないが、Jira 環境全体の シンボリックリンク版 を最新状態に保つデーモンはどうだろう
      元ファイル用の jira-as-filesystem を1つ置き、人が探索して操作するためには、同じファイルを関連する複数の場所に複数のリンクとして配置したシンボリックリンクツリーを用意する方式だ
      理解不足で必要以上に層を増やしているのかもしれないが、技術的には今述べた抽象化の問題を解けそうだ
    • Unix ファイルシステムでは、同じ対象を2通りの方法で参照するのは一般的だ
      現代の Linux ではディスクをブロックデバイスと UUID の両方で参照するので、このアプローチは妥当で期待にも沿っていると思う
      ただ個人的には、JIRA 自体が十分に複雑なので使わない気がする
    • GitHub には jirafs 系がかなりある
      例: https://github.com/coddingtonbear/jirafs
    • 単に 1234-human-sense のようにすればいいのでは？
      2種類の情報をどちらも含んでいて、パースもしやすそうだ
    • 作ったソリューションを オープンソース として公開する可能性はあるだろうか？

  • トレードオフ、性能、機能がそれぞれ異なる FUSE のマウントオプションは本当に多い
    s3fs、goofys、seaweed、minio、Google Drive などもあるし、JuiceFS はオブジェクトストレージをマウントしたうえで、従来のファイルシステムに期待するメタデータを備えた POSIX 方式でアクセスする用途としてかなり興味深い
    https://juicefs.com

  • いいね
    関連する質問として、最近はより広くサポートされているプロトコルなので、NFS ベースのファイルシステム を実装する例を見かける
    rclone は Mac でこの方式を使っているようだが、このアプローチに関するガイドや比較資料はあるだろうか？

    • 面白いことに、最近の macOS では macFUSE をインストールするのにセキュリティ機能を無効化する必要があるが、優れた fuse-t がある
      ほぼ代替品のように動作し、カーネル拡張も不要で、バックグラウンドで NFS サーバーを立ち上げて macOS の機能でマウントする
      性能もかなり良い
    • Rust の例: https://github.com/xetdata/nfsserve

  • 完成形の製品がどんなものか見たいなら、仮想ファイルシステムを備えた音楽マネージャー azuline/rosé を見るとよい
    コメント、説明、型、テストが豊富な素晴らしいコードベースなので、学びやすいはずだ
    https://github.com/azuline/rose

  • FUSE に興味があるなら、対になるプロジェクトである CUSE も面白いかもしれない
    CUSE はユーザー空間の文字デバイスドライバエミュレーションで、新しいカーネルモジュールをコンパイルせずにハードウェアを模倣できるようにしてくれる
    最近、Python で IOCTL をサポートするハードウェアデバイスを書くために使った
    簡単に動く良い Python ライブラリも見つからず、ドキュメントも乏しかったが、最終的には ctypes FFI ライブラリだけで十分に書けた
    カーネルドライバを書いたことがない立場から見て、すぐには直感的でなかった唯一の点は、IOCTL では各読み書きごとにバッファサイズを再調整する必要があるため、呼び出しがペアで入ってくることだった
    幸い、CUSE には入出力バイトをすべて表示するデバッグモードがある
    CUSE はもともとユーザー空間のサウンドデバイスを作るために実装されたが¹、カスタム TTY のような用途にも使われ、私は仮想 SPI デバイスを作るのに使った
    誰かの役に立って、このプロジェクトがもっと注目されるといいと思う
    ¹ https://lwn.net/Articles/308445/

  • かなり前に、dokuwiki という Wiki システムとやり取りするための Python FUSE ファイルシステム[1] を作ったことがある
    それは llfuse[2] の上に作ったが、dokuwiki と直接関係のない低レベル API をかなり多く実装する必要があった
    そこで、dokuwiki の実装とは無関係な部分を包むラッパーとして easyfuse[3][4] を作ったので、FUSE システムを作るつもりなら見てみる価値はある
    [1]: https://github.com/JelteF/dokuwikifuse
    [2]: https://pypi.org/project/llfuse/
    [3]: https://pypi.org/project/easyfuse/
    [4]: https://github.com/JelteF/easyfuse

    • dokuwiki 用 FUSE を作った ユースケース が何だったのか気になる
      基本的に dokuwiki はテキストファイルの集まりなのだから、NFS でマウントしたり Dropbox/Syncthing で共有したりするほうが、もっと単純で効率的ではないだろうか？

  • FUSE は、Makefile が任意のリソースの上に 有向非巡回グラフ を指定できるようにする仕組みだと考えるとよい
    たとえば k8s クラスターの状態を公開する FUSE ファイルシステムがあれば、私のような単純な頭でも扱えるオペレーターを書きやすくなるかもしれない
    メールも同様で、IMAP をファイルシステムとして公開すれば、RAG アプリ（gpt4all のようなもの）があらゆるものに直接アクセスできるのではないか？

  • 話題から外れるが、90年代/2000年代っぽい雰囲気のブログを見ると、私はいつも最初の投稿ページに行く
    gwolf.org もそうだが、そういう タイムカプセル をのぞき込むのはいつだって期待を裏切らない