index ファイルは index_mmap_invalidate = yes の設定をるすことにより、 NFS 越 しで保存することができます。index ファイルはローカルにまったくキャッシュされ ることがないので、これは良い考えではないかもしれません。ネットワーク経由でそ れを度々再読み込みすることは、単純にメールファイルに直接アクセスすることより も効率的ではありません。 NFS 越しにメールボックスを保存している間、 index ファイルをローカルに保存する ことは、良い方法です。ローカルの index ファイルは常に完全な同期をする必要はな く、そのため、いくつかのマシンでメールボックスにアクセスしても問題ではありま せん。クラスタの環境では、可能であればユーザを同じマシンに導いておけば、より 良いです。 そのため、 default_mail_env に :INDEX=MEMORY もしくは :INDEX=/local/var/indexes/%u をどちらか追加してください。 - .customflags ファイルは現在、ロックの際 fcntl() で必要になります。多くの NFS サーバは、少なくとも別々の lockd デーモンなしで、それをサポートしてい ません。これは、デフォルトで NFS の安全のために、将来修正する予定です。 .customflags は mbox では index に含まれているので、これは Maildir のとき のみの実際の問題です。 - ユーザのメールボックスをアクセスするそれぞれの IMAP サーバで、 gethostname() は異なるホスト名を返さなければなりません - 時刻を合わせられなければなりません、そうしないと起動に失敗します。 もし、_本当に_ NFS 経由で index を使ってみたいならば： - index_mmap_invalidate = yes に設定します - index で fcntl() ロックを要求します。 .lock ファイルはかなり遅いですが、 ログの修正以外では可能です。 NFS を使って index をうまく作成するやり方の考え： 読み込みにはロックを必要としませんので、編集するときのみ、莫大な操作を行いま す。それは、以下を含んでいます： - rename() を使って完全にファイルを置き換えます - 一度に複数バイトを書き込むことは莫大であることを仮定できません。もし、よ り大きなデータセットを編集する必要があるときは、以下のようにします： - 構造体 struct { bit_t use_first; dataset_t first; dataset_t second; } - 読み込み時は、もし use_first を設定されていれば first を使い、設定され て居なければ、 secont を使います。 - 書き込み時は、使っていない変数に最初に書き込み、そのときに flag を更新 します。 - これはもちろん、データセットの余分な１ビットのため、空き容量を２倍必要 としますので、多くは使えません。 - もしデータがセットされるだけであって、変更が行われなければ、データが セットできるかどうか指定するので、余分の１ビットのみを必要とします。 - ファイルの終わりに新しいデータを追加します。ヘッダーに used_file_size を 持たなければならないので、上記のようにします。 - それぞれのキャッシュされたメッセージの記録は、次の部分へのポインタをもって いますので、さらなるキャッシュデータはファイルに追加することができます。 メッセージフラグは最も一般的な修正されたデータです。もし、それを直接編集する 場合、同時読み込みは部分的にのみ変更を捕らえるかもしれません。しかし、幸運な ことに、これは認められたふるまいですので、それをすることができます。 もう１つの一般的な修正されたデータは mailfir ファイル名です。index ではベー スネームのみを保存し、ローカルにのみ同期されたフルネームを保持したいです。 index ファイルから使っていないデータを圧縮することは、 index.lock ファイルに index を再書き込みして、 index ファイル上にその名前の変更をすることによって されなければなりません。 全てのファイルの操作は、ネットワークトラフィックの増加を抑えるために、 lseek() と read() と write() によって行われなければならないでしょう。それは 賢い先読みキャッシュとなるでしょう。