[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[postfix-jp:02009] Re: NFSをMaildirで利用した時の安全性
- Subject: [postfix-jp:02009] Re: NFSをMaildirで利用した時の安全性
- From: "y yasuto" <yyasuto@xxxxxxxxxxx>
- Date: Tue, 03 Sep 2002 11:21:45 +0900
やすとめです。
妻井さん、荒木さん、ご返答ありがとうございます。
妻井さん:
NFS環境下Maildir形式での排他処理に関する問題は無い(関係無い)、
という事の確認ありがとうございます。
複数台にする理由は、
> - 1台のマシンでは /var/spool/mail がいっぱいであふれる
> - POP or IMAP アクセスが集中して重いから分散させる
はい。この通りです。
ただ、増設時もドメインは同じにしたいんです。
Virturalテーブルを使う事になりますよね。
>MX からスプールホストに振り分ければ、
>ユーザーのメイルアドレス(ドメイン)は同じに見せられますし。
ハブ/スポーク型でVirtualテーブルを使用し、メールハブからメールスポークに
メッセージを振り分ける方法(仮想ホスティング)がある事は参考書にありました。
これですと、メールハブにMXが振られる様ですが、これとは違う方法でしょうか?
違う様でしたら、MXをそれぞれのスプールホストに振ることで、
ドメインを同じに見せられる様にする方法を教えて頂けないでしょうか。
荒木さん:
気になっていた所を指摘して頂きました。ありがとうございます。
>Postfixのlocal、virtualに関してはMaildir形式で配送させても、
>必ずしも別プロセスにはなりません。
>Postfixでは同プロセスで複数配送する場合は、
>file名はstarttime.pid_count.hostとなります。
>countはそのプロセス内で個々の配送先につけます。
ファイル名にその"count"が付いているのがqmailのファイル名と違っている部分が
少し気になってました。
"count"番号は0,1,2・・・と順についていくようですが、
この部分はqmailのMaildirの拡張のようなイメージでしょうか?
>maildir形式ではfileのメタデータはfile名からとることができるため、
>ほとんど使用しないで済みますが、async時ならメタデータと実データの不一致、
>sync時ならボトルネック源となる可能性があるため、より注意した運用が
>必要になるでしょう。
より注意した運用が必要、と書かれているので、大切な内容かと思うのですが、
申し訳ないのですが、syncに関して知識があまりありません。
もし、許されるのでしたら、もう少し説明を頂けると嬉しいです。
度々とお邪魔しておりますが、
もう少しだけお付き合いして頂けますでしょうか。
よろしくお願い致します。
>From: ARAKI Yasuhiro <yasu@xxxxxxxxxxxx>
>Reply-To: postfix-jp@xxxxxxxxxx
>To: postfix-jp@xxxxxxxxxx
>Subject: [postfix-jp:02008] Re: NFSをMaildirで利用した時の安全性
>Date: Tue, 03 Sep 2002 09:48:48 +0900 (JST)
>
>荒木です。
>
> > はじめまして。
> > やすとめと申します。
>
> > Maildir形式の場合、lockが必要なく、各メッセージを常に別プロセスで
> > 配送しているので、NFSでも問題は
> > 無いと思う(複数ホストからのアクセスも大丈夫?)のですが、
> > 何か確証となる情報がありましたら、と思います。
>
>Postfixのlocal、virtualに関してはMaildir形式で配送させても、
>必ずしも別プロセスにはなりません。
>Postfixでは同プロセスで複数配送する場合は、
>file名はstarttime.pid_count.hostとなります。
>countはそのプロセス内で個々の配送先につけます。
>
> >そもそも、Maildir形式はlockを必要としないわけですが、
> >ファイルロックの効かない NFS 環境下でも安全なのか?
> >(/home/$USER/Maildir/の時とファイル処理に違いはないのか?)という事で
す。
>
>そもそも使用していないのでlockに関しては、形式違いや実装上の問題はありませ
ん。
>maildir形式ではfileのメタデータはfile名からとることができるため、
>ほとんど使用しないで済みますが、async時ならメタデータと実データの不一致、
>sync時ならボトルネック源となる可能性があるため、より注意した運用が
>必要になるでしょう。
>
>--
>荒木靖宏
>
_________________________________________________________________
かわいくて愉快なイラスト満載 MSN キャラクター http://character.msn.co.jp/
[検索ページ]
[Postfix-JP ML Home]