CNID バックエンド

CNID バックエンド
- dbd
- mysql
- sqlite

SMB や NFS のようなほかのプロトコルとは異なり、ほとんどの場合、AFP プロトコルはファイルやディレクトリをパスではなく ID を通して参照している。その ID は CNID とも言われ、カタログ・ノード ID (Catalog Node ID) の略である。典型的には、まず AFP リクエストで、例えば、“サーバーさん id 167 のディレクトリにある、ファイル名 ‘Test’ というのを開いてください。”といった調子でディレクトリ IDとファイル名を用いる。例えば、Mac での “Aliases” は基本的には ID として作用する（より最近の AFP クライアントでは絶対パスにフォールバックするが、これは Finder のみで当てはまることであり、アプリケーションでは当てはまらない）。

AFP ボリューム内のすべてのファイルは一意のファイル ID を持たなければならず、AFP 仕様によると CNID は再利用されてはならない。ID は 32 ビットの数値であり、ディレクトリは同じプールを共有するため、約 40 億のファイルとディレクトリが書き込まれた後に枯渇する。

その後に何が起こるかはバックエンドによって異なる。dbd バックエンドは ID の割り当てを停止し、新しいファイルはボリュームに書き込めなくなる。sqlite および mysql バックエンドは CNID テーブルを空にし、番号付けを再開し、ボリュームに接続されているすべてのクライアントに再接続をトリガーして、すべてのクライアントが新しい ID を使用するようにする。これにより長期間使用されるボリュームを引き続き書き込み可能に保つことができるが、仕様に違反し、古い ID を指す Mac のエイリアスを壊してしまう。両方のバックエンドは、ボリュームが上限に近づくと警告をログに記録するので、オプションとして、メンテナンスウィンドウ中に dbd ユーティリティで事前に番号を再割り当てすることができる。

Netatalk はホストのファイルシステム内で ID とファイルあるいはフォルダーのマップ（ID との対応付け）をする必要がある。それを実現するためにいくつかの異なる CNID バックエンドが用意されていて、afp.conf 設定ファイル内で cnid scheme オプションで選択が可能である。CNID バックエンドは基本的には、ストアされた ID ↔ 名前を一対一対応させるデータベースである。

設定の必要ないCNIDバックエンドの場合、CNIDデータベースはデフォルトではシステムの状態ディレクトリパス（例：/var/lib）の下にある netatalk/CNID サブディレクトリに置かれる。コンパイル時に -Dwith-statedir-path=PATH オプションで場所を変えられる。

dbd コマンドラインユーティリティは、dbd バックエンドだけでなく、任意のバックエンドの CNID データベースを検証、修復、および再構築できる。

【注記】以下の CNID 関連の考慮事項を念頭に置くと良い:

vol dbnest = yes が指定してある時以外はボリュームをネスト（入れ子）にしてはならない。
CNIDバックエンドはデータベースである。それ故 afpd はファイルサーバーとデータベースの混成物とならしめている。
もしファイルシステムに空き容量がなくなった場合、データベースは破損するかもしれない。それを回避するために取る策としては、 vol dbpath オプションを使用して、データベースファイルをどこか別の場所に置く、か、クオータを使っているならばCNIDデータベースフォルダーがクオータなしでユーザー／グループのオーナーとなっているか確認する。のいずれかである。
NFS 経由でマウントされているボリュームのCNIDデータベースには注意すべきである。いずれにしろそのような構成にすると決める事自体かなり無謀である。が、さらにデータベースもその上に置くとなると決定的にトラブルの元となる。要はデータベースの破損である。もしどうしてもNFSマウントしたボリュームを使わねばならない場合はデータベースをローカルディスクに置くために vol dbpath ディレクティブを使用するべきである。

以下は、netatalk に含まれる様々な CNID バックエンドの説明がある。コンパイル時に、これらのバックエンドを1つまたは複数選択してビルドできる。使用可能なバックエンドとデフォルトのバックエンドを確認するには、コマンド afpd -v を実行すること。