cnid_dbd — CNIDデータベースへのアクセスデーモン
cnid_dbd
cnid_dbd -v | -V
cnid_dbdはストレージとカタログノードID (CNID)と関連情報の検索のためのインターフェースをafpdデーモンに提供する。CNIDはMacintoshベースのファイルシステムの構成要素であるが、これの動作は単純にはUnixファイルシステム上にマッピングできない。従って、一つのデータベース内に分離した記憶域が必要となる。cnid_dbdはafpdのCNIDバックエンドの一つであり、dbdバックエンドを実装する。
cnid_dbdはコマンドラインやシステム起動スクリプトではなく、cnid_metadデーモンによって起動する。netatalkボリューム一つにつき、cnid_dbdのインスタンスが一つである。
cnid_dbdはBerkeley DBデータベースライブラリを用いて、トランザクションで保護したアップデートを行う。トランザクションによるdbdバックエンドは、たとえシステムが不意にクラッシュしても、CNIDデータベースの破損を防ぐだろう。
cnid_dbdは起動時にcnid_metadからの有効なユーザIDとグループIDを継承する。普通、この動作はnetatalkボリュームをクライアントへ提供するafpdによって生じる。それはボリュームに関連付けられたBerkeley DBデータベースのホームディレクトリdbdirを変更する。もしcnid_metadから継承したユーザIDが0 (root)ならば、cnid_dbdはユーザIDとグループIDをデータベースホームディレクトリの所有者とグループに変更する。そうでない場合は、継承した値を使い続ける。このとき、cnid_dbdはデータベースを開き、ファイル記述子clntfdを使って要求されたものを提供開始する。同じボリュームへアクセスしようとする次のafpdのインスタンスは、ファイル記述子ctrlfdを用いるcnid_metadによって、既に動いているcnid_dbdへリダイレクトされる。
cnid_dbdは、永久に動作するか、または不活性期間の後に終了するかを設定できる。もしcnid_dbdがTERMやINTシグナルを受け取った場合、汚れたデータベースバッファをディスクにフラッシュし、Berkeley DBデータベース環境を閉じてから、綺麗に終了する。この方法でcnid_dbdを終了するのは安全な事であり、もし必要なら再起動する。他のシグナルは処理されず、即座に終了するか、もしかすると(トランザクションなしのとき)CNIDデータベースを矛盾した状態のままにしておくか、(トランザクションありのとき)リカバリ中の直近の更新を失うかするだろう。
Berkeley DBデータベースサブシステムは、データベースのホームディレクトリdbdirにlog.xxxxxxxxxxという名前のファイルを作る。ここでxxxxxxxxxxは、単調増加する整数である。これらのファイルにはトランザクションにおけるデータベースの変更が記載されている。これらのファイルは、db_param設定ファイル(以下を見よ)でlogfile_autoremoveの値が0 (デフォルトは1)に設定されている場合を除いて、定期的に削除される。
cnid_dbdは起動時、データベースディレクトリdbdir の中のファイルdb_paramから設定情報を読む。ファイルがない場合やパラメータが載っていない場合、適切なデフォルト値が使われる。ひとつのパラメータのフォーマットは、まずパラメータ名、それに続く一つ以上のスペース、それに続くパラメータ値、それに続く改行で構成される。現在以下のパラメータが認識される:
もし0を設定した場合、cnid_dbdの起動時に未使用のBerkeley DBトランザクションのログファイル(データベースホームディレクトリの中のlog.xxxxxxxxxx)の定期的な削除が行われない。デフォルトは1。
Berkeley
DBのキャッシュサイズをキロバイト単位で決定する。デフォルトは8192。それぞれのcnid_dbdプロセスは通常のメモリ占有量に加えて大量のメモリを獲得する。これはデータベースのパフォーマンスを調整するのに使われる。Berkeley
DBに附属するdb_statユーティリティに-mオプションを付けると、この値を変更すべきかどうかを決定するのに役立つ。デフォルトではキャッシュが要求の大半を丁度良く満たすように極めて保守的な値になっている。メモリがシステムのボトルネックにならないなら、あなたはその値を放置してよい。Berkeley DB Tutorial and Reference
Guideには、より詳しい情報を記したSelecting a cache
sizeという章がある。
flush_frequency (デフォルト: 1000)とflush_interval (デフォルト: 1800)はデータベースへの変更を書き戻す頻度を制御する。これらの両方動作は、i) flush_frequencyを越える要求を受け取った場合、ii) 最後の保存/書き戻しからflush_interval秒よりも経過した場合のどちらかで実行される。ディスクキャッシュ設定のため、あなたのハードディスク設定の確認に慎重を期してください。多くのIDEディスクはデフォルト動作では書き込みを単にキャッシュするだけです。従って、たとえデータベースファイルをフラッシュしても期待した効果は得られないでしょう。
afpdクライアントがcnid_dbdで処理するために開く最大の接続数(ファイル記述子数)。デフォルトは512。この値を超えた場合、存在する接続のうち一つを閉じて再利用する。影響を受けたafpdプロセスは後に透過的に再接続される。これは僅かなオーバヘッドを生じる。一方、全ての記述子をselect()システムコールでチェックしなければならないので、このパラメータを極めて高い値に設定するとcnid_dbdのパフォーマンスに影響するかもしれないし、更に悪いことにプロセスあたりに開くファイル記述子のシステム上の上限を超えるかもしれない。たった一つのafpdクライアントプロセスが動作すると予想されるボリュームでは、この値を1に設定すると安全である。例えばホームディレクトリである。
アイドリング中のcnid_dbdが終了するまでの静止状態の秒数。デフォルトは600。これを0に設定するとタイムアウトが無効になる。
Netatalk 2.1の後に出た最初のバージョン、すなわちNetatalk 2.1.1は、手動操作なしに自動的にBerkeley DBアップデートをサポートすることに注意せよ。言い換えると、Netatalk 2.1はBerkeley DBデータベースのアップグレードを準備するコードと、既に準備されている場合にそれをアップグレードするコードを含んでいる。これはバージョン2.0.xからはアップグレードできないことを意味する。なぜならデータベースの準備をしていないからである。
異なるバージョンのBerkeley DBライブラリを使っている古いNetatalkをアップデートするためには、以下の手順をとります:
これからアップグレードする古いバージョンのNetatalkを停止する
古いBerkeley DBユーティリティを使って、db_recover -h <.AppleDBのパス> を実行する
新しいBerkeley DBユーティリティを使って、db_upgrade -v -h <.AppleDBのパス> -f cnid2.db を実行する
再び新しいBerkeley DBユーティリティを使って、db_checkpoint -1 -h <.AppleDBのパス> を実行する
新しいバージョンのNetatalkを起動する
