FUSE readdir() 操作で照会を正しく実装します。

readdir()私はおもちゃのファイルシステムを実装しようとしており、効率的でスケーラブルな方法でそれを正しく実行する方法を見つけようとしています。 FUSEが使用するインタフェースを理解するために、主にマニュアルを読んだ。パイヒューズ3しかし、他のFUSEラッパーを使用しても問題は解決されるとは思いません。

私の理解は私が実装するときreaddir()呼ばれると、呼ばれることを期待したreaddir_reply()メソッドが返されるまで、連続したディレクトリエントリを持ちますFalse。これを実行するときは、各エントリを名前と呼ばれる一意の[1] 64ビットIDに関連付けたいと思いますnext_id。次の呼び出しはreaddir()これらのIDの1つを受け取り、前の呼び出しからそのIDが返されると予想されます。 IDに関連付けられたエントリの後に始まるディレクトリエントリ。

呼び出し間でディレクトリが変更された場合（項目の追加または削除など）、連続呼び出しreaddir()から追加された項目を含めるか削除した項目を省略するかを自由に選択できますが、他のすべての項目はIDを保持する必要があります。スキップまたは2回返されます。

意味では、これらすべてが私にとっては大丈夫だと思います。私が考えることができる最も簡単な実装は、すべてのディレクトリエントリを配列として読み込み、配列内opendir()の各エントリのインデックスをIDとして使用することです。すべての項目を一度に読みたくない場合は、呼び出すたびreaddir()に配列を構築できます。ただし、ファイルハンドルを解放する前に配列[2]を消去することはできません。

最新のファイルシステムは、数億のファイルを含むディレクトリを簡単に処理できます。私は、これらの実装がディレクトリファイルハンドルごとのディレクトリエントリ数の順序でメモリ割り当てを許可できないと仮定します（たとえば、1000万ファイル×エントリあたり100バイト= 1GB）。これらのファイルシステムは通常、FUSEを介さずにカーネルにほぼ排他的に実装されています。

これらすべての事実は、以下の記述の少なくとも1つが事実であるという結論を下します。

1. FUSEの動作要件を誤って理解しましたreaddir()。
2. 私が見ることができないこれらの要件を満たすより効率的なソリューションがあります。
3. カーネル内のファイルシステムに実装できるより良いAPIがありますが、このAPIはこの状態を維持する必要はありません。
4. ファイルシステムは、readdir()同等の機能を正しく実装しませんが、代わりにアプリケーションが通常気にしない方法で実装します。
5. ファイルシステムはディレクトリをナビゲートするときにギガバイトのメモリを割り当てますが、誰もそれを気にしません。

だからそれはどれですか？

readdir()他のファイルシステム実装が一​​般的に満たすすべての期待を満たす方法でFUSEタスクを効率的に実装する方法を理解したいと思います。

[1]: 単一ファイルハンドル内で一意です。
[2]：またはreaddir()呼び出し時start_idに設定することもできます0。