netatalk.io

Netatalk 4.5.0

ディレクトリキャッシュの調整

Netatalk の dircache（ディレクトリキャッシュ）は、ファイルとディレクトリの高度なマルチレイヤーキャッシュで、ファイルシステムの stat 情報、AppleDouble メタデータ、およびリソースフォークを含む。

最初のディレクトリ列挙中にキャッシュが構築されると、その後の操作はメモリから直接キャッシュされたデータを返すようになる。これにより、非常に大きなワーキングセットでも高速な操作が可能になる。AFPユーザーがファイルやディレクトリを名前変更または削除すると、dircacheエントリーはすべてのユーザーのために更新または削除される。dircacheは常にAFP操作と同期されているが、Netatalkの外部で行われた変更（例：ローカルファイルシステムの変更やSambaなどの他のファイル共有サービスによる変更）を検出しない。

デフォルトでは（dircache validation freq = 1 の場合）、Netatalk はキャッシュエントリーがストレージレイヤーとまだ一致していることを検証するために、すべてのアクセスで stat() 操作を実行する。キャッシュはほとんどのI/O操作を回避するが、この ctime チェックは多少のオーバーヘッドを追加する。Netatalk がストレージボリュームにアクセスする唯一のプロセスである場合は、高い dircache validation freq 値（例：100）を設定して、これらの余分な stat() 呼び出しのほとんどをスキップし、ストレージとページキャッシュレイヤーの負荷を減らすことができる。

dircacheエントリーがアクセス時に古いと判断された場合、Netatalkは問題を優雅に検出し、ストレージから最新の状態でエントリーを再構築し、invalid_on_use カウンターをインクリメントする。invalid_on_use カウンターを使用して、外部の変更がまれであるが最大のパフォーマンスがまだ望ましい環境で dircache validation freq を調整することができる。

dircache size = number (G)

キャッシュ内のエントリーの最大数。与えられた値は、最も近い2のべき乗に切り上げられる。各エントリーは約192バイト（64ビットシステムの場合）を占め、接続されたユーザーごとに各afpd子プロセスが独自のキャッシュを持つ。dircache size を構成するときは、ユーザーの数を考慮すること。

デフォルト：65536、最大サイズ：1048576。

dircache validation freq = number (G)

外部変更検出のためのディレクトリキャッシュ検証頻度。 netatalk の外側で行われた変更を検出するために、キャッシュされたエントリーがファイルシステムに対してどのくらいの頻度で検証されるかを制御する。（例：他のプロセスによる直接的なファイルシステムの修正）。1 の値は、毎回のアクセスでキャッシュを検証することを意味する（互換性のためのデフォルト）。より高い値は検証頻度が低くなる。例えば、5 は 5 回に一度キャッシュエントリーを検証することを意味する。より高い値はパフォーマンスを向上させ、ストレージ IO とページキャッシュのストレスを大幅に削減するが、Netatalk の外側での変更の検出が遅れる可能性がある。

デフォルト：1、範囲：1-100。

内部の netatalk 操作（ファイル／ディレクトリの作成、削除、名前変更）は、この設定に関係なく、常に dircache エントリーを即座に更新にする。Netatalk がボリュームにアクセスする唯一のプロセスである場合、最大のパフォーマンスのために 100 の値を安全に設定できる。

dircache mode = lru | arc (デフォルト: lru) (G)

キャッシュ置換アルゴリズム。Netatalk は 2 つのキャッシュエビクションポリシーをサポートする：

• LRU（最も最近使用されていない） — レガシーアルゴリズムでデフォルト。アクセス時間順に並べられた単一のリストを維持する（FIFO）。キャッシュがいっぱいになると、最も最近アクセスされていないエントリーが削除される。シンプルでメモリー効率が良い。

• ARC（適応型置換キャッシュ） — より良いキャッシュヒット率を達成するために、新しさ と 頻度 を動的にバランスさせる最新の自己調整アルゴリズム。「LRUを上回る適応型置換キャッシュアルゴリズム」（Megiddo & Modha、IBM、2004）に基づいている。

ARCは観測されたアクセスパターンに適応するため、時間的局所性と頻度ベースの再利用を組み合わせたワークロードに対して効果的である。例えば、ユーザーが最近アクセスしたファイルやディレクトリと頻繁にアクセスしたファイルやディレクトリを交互に切り替える場合など。ARCは4つのリストを維持する：キャッシュされたエントリーのための2つのリスト（T1最近、T2頻繁）と、最近削除されたエントリーを追跡する2つのゴーストリスト（B1、B2）。ゴーストエントリーが再アクセスされると、ARCはミスから学習し、ポリシーを調整する。このゴースト学習とセグメンテーションがARCをLRUと区別するものであり、またARCをLRUキャッシュをフラッシュする可能性のあるシーケンシャルスキャンやバックアップに対して耐性のあるものにしている。

Netatalk の ARC は、完全なゴーストエントリーを使用する（すべての内容を保持する） IBMの論文のメタデータのみのゴーストではなく、 キャッシュエントリーが小さいため。 ゴーストヒットは、ファイルシステムのルックアップなしですぐにキャッシュに昇格されるため、 ARCはエッジケースでは常にLRUと同等以上のパフォーマンスを発揮し、 その他すべてのケースでより良いパフォーマンスを発揮するはずである。

メモリ： ARCはLRUの約2倍のメモリを使用する なぜなら、c キャッシュされたエントリーと並行して最大 c ゴーストエントリーを追跡するからである （ここで c は dircache size）。 各エントリーは64ビットシステムで約192バイトである。 それでも、ARCは同じ総メモリのLRUキャッシュよりも優れたパフォーマンスを発揮する。

デフォルトの dircache size 65536の場合：LRUは約12 MB、ARCは接続されたユーザーごとに約24 MB。

推奨：RAMが4 GB以上のサーバーには arc を使用すること。 メモリが制約されているシステムには lru を使用すること。

デフォルト：lru。

リソースフォークのキャッシュ

Netatalk は、リソースフォークデータ（クラシックMac OSのAppleDouble ._ データ、または現代のmacOS/Linux/UNIXシステムの拡張属性）をオプションでtier-2 dircacheレイヤーにキャッシュすることができる。これにより、AFPクライアントがFPGetFileDirParamsやFPEnumerateでディレクトリを列挙し、リソースフォークデータを要求する際の繰り返しのストレージI/Oを回避することができる。リソースフォークは、フォルダのカバーアート（icnsデータ）などの多くのmacOSデータ構造を格納する。例えば、カスタムディレクトリアイコンを設定するユーザーは、リソースフォークキャッシュレイヤーから大幅なパフォーマンス向上を観察することができる。

リソースフォークのキャッシュはデフォルトで無効になっており、2つの設定で制御される：

dircache rfork budget = number (デフォルト: 0) (G)

接続されたユーザーごとにリソースフォークデータをキャッシュするためのKB単位の総メモリ予算。0に設定すると（デフォルト）、リソースフォークのキャッシュが無効になる。

最大：10485760（KB単位で10 GB）。

dircache rfork maxsize = number (デフォルト: 1024) (G)

キャッシュされる単一のリソースフォークエントリーの最大サイズ（KB単位）。この値より大きいリソースフォークは、総予算にスペースが残っていてもキャッシュされない。

最大：10240（KB単位で10 MB）。

ファイルの ctime や inode は更新されたり、または AFP クライアントはリソースフォークを更新されたりした場合にキュアッシュされたエントリーは無効になる。予算は超過される場合に LRU/ARC 順にエントリが削除される。

例 （100 MB rfork 予算、エントリー毎に最大 5 MB）：

dircache rfork budget = 102400
dircache rfork maxsize = 5120

例（Netatalk のみがボリュームにアクセスする場合）：

dircache validation freq = 100

例（大きなキャッシュを伴うファイル集約型ワークロードの場合）：

dircache size = 262144
dircache validation freq = 100
dircache mode = arc

【注記】 afpd が正常にシャットダウンした時（ユーザーが切断した時）に Netatalk ログファイルで “dircache statistics:” 行をチェックして dircache の有効性を監視すること。