Netatalk 4.5.0
CNID バックエンド
SMB や NFS のようなほかのプロトコルとは異なり、ほとんどの場合、AFP プロトコルはファイルやディレクトリをパスではなく ID を通して参照している。その ID は CNID とも言われ、カタログ・ノード ID (Catalog Node ID) の略である。典型的には、まず AFP リクエストで、例えば、“サーバーさん id 167 のディレクトリにある、ファイル名 ‘Test’ というのを開いてください。”といった調子でディレクトリ IDとファイル名を用いる。例えば、Mac での “Aliases” は基本的には ID として作用する（より最近の AFP クライアントでは絶対パスにフォールバックするが、これは Finder のみで当てはまることであり、アプリケーションでは当てはまらない）。
AFP ボリュームにある各々のファイルに一意のファイル ID が割り当てられる。仕様により CNID は絶対に再利用禁止であり、32 bit の数字である。ディレクトリ ID も同じ ID プールを使用する。このため、ある AFP ボリュームにおよそ 40 億個以上のファイル・フォルダーを書き込むと、その時点で ID プールが枯渇され、当該ボリュームへの新ファイルの書き込みができなくなる。Netatalk の CNID バックエンドの一部は、利用可能な ID を使い果たした後に再利用しようとする場合がある。これは厳密的には仕様違反にはなるが、長期間有効なボリュームでは継続的な使用可能にする。
Netatalk はホストのファイルシステム内で ID とファイルあるいはフォルダーのマップ（ID との対応付け）をする必要がある。 それを実現するためにいくつかの異なる CNID バックエンドが用意されていて、afp.conf 設定ファイル内で cnid scheme オプションで選択が可能である。CNID バックエンドは基本的には、ストアされた ID ↔ 名前を一対一対応させるデータベースである。
設定の必要ないCNIDバックエンドの場合、CNIDデータベースはデフォルトではシステムの状態ディレクトリパス（例：/var/lib）の下にある netatalk/CNID サブディレクトリに置かれる。コンパイル時に -Dwith-statedir-path=PATH オプションで場所を変えられる。
CNID データベースの検証・修復・再構築のために用いることができる dbd という名のコマンドが用意されている。
【注記】 以下の CNID 関連の考慮事項を念頭に置くと良い:
- vol dbnest = yes が指定してある時以外はボリュームをネスト（入れ子）にしてはならない。
- CNIDバックエンドはデータベースである。それ故 afpd はファイルサーバーとデータベースの混成物とならしめている。
- もしファイルシステムに空き容量がなくなった場合、データベースは破損するかもしれない。それを回避するために取る策としては、 vol dbpath オプションを使用して、データベースファイルをどこか別の場所に置く、か、クオータを使っているならばCNIDデータベースフォルダーがクオータなしでユーザー／グループのオーナーとなっているか確認する。のいずれかである。
- NFS 経由でマウントされているボリュームのCNIDデータベースには注意すべきである。いずれにしろそのような構成にすると決める事自体かなり無謀である。が、さらにデータベースもその上に置くとなると決定的にトラブルの元となる。要はデータベースの破損である。もしどうしてもNFSマウントしたボリュームを使わねばならない場合はデータベースをローカルディスクに置くために vol dbpath ディレクティブを使用するべきである。
以下は、netatalk に含まれる様々な CNID バックエンドの説明がある。コンパイル時に、これらのバックエンドを1つまたは複数選択してビルドできる。使用可能なバックエンドとデフォルトのバックエンドを確認するには、コマンド afpd -v を実行すること。
dbd
「データベースデーモン」（dbd）バックエンドはBerkeley DB上に構築されている。CNID データベースへのアクセスは cnid_dbd デーモンプロセスのみに制限されている。afpd プロセスは cnid_dbd データベースの読み込みと更新のために cnid_dbd デーモン とやりとりをする。全ては cnid_metad デーモンによって制御されている。
本バックエンドは非推奨であり、新規導入の際に選択しないことを推奨する。
mysql
MySQL または MariaDB サーバーを使用する CNID バックエンド。これは最も高性能でスケーラブルなバックエンドオプションであり、多数の同時ユーザーがいる大規模な展開に推奨される。
SQL サーバーはシステム管理者がプロビジョニングする必要があり、Netatalkをデータベースに接続する設定する必要もある。
sqlite
SQLite v3 組み込みデータベースエンジンを使用する高速で軽量な CNID データベースバックエンド。データベースは afpd によって直接アクセスされるため、dbd と比べてシンプルなアーキテクチャを持ち、mysql と比べて、システム管理者が別の SQL サーバーをセットアップして維持する必要もない。
トレードオフとして、SQLite の組み込みデータベースは同時書き込み操作に対して最もスケーラブルなものではない。したがって、同時ユーザーが 20 人までの展開や、MySQL や MariaDB をセットアップしたくないシステム管理者に推奨される。
