20
<p> This question was asked on the postfix-users mailing list a
23
<blockquote> <p> Also, what considerations are there for file
24
locking or other potential problems when running Postfix with a
25
Netapp-style box for /var/mail delivery? I know that FreeBSD has
26
broken NFS file locking (both client and server?) but I'm not sure
27
if this is something Postfix can work around or not. </p> </blockquote>
29
<p> Postfix jumps several hoops in order to deal with NFS-specific
30
problems. Thus, Postfix on NFS is slightly less reliable than
31
Postfix on a local disk. That is not a problem in Postfix; the
32
problem is in NFS and affects other MTAs as well. </p>
34
<p> For queue locking within Postfix, NFS is not an issue because
35
you cannot share Postfix queues among multiple Postfix instances.
38
<p> In order to have mailbox locking over NFS, you have to configure
39
everything to use fcntl() locks for mailbox access (or switch to
40
maildir style, which needs no application-level lock controls).
43
<p> To turn on fcntl() mailbox locks with Postfix you specify: </p>
48
<a href="postconf.5.html#virtual_mailbox_lock">virtual_mailbox_lock</a> = fcntl
49
<a href="postconf.5.html#mailbox_delivery_lock">mailbox_delivery_lock</a> = fcntl
53
<p> Obviously, this approach is useful only if all other mailbox
54
access software also uses fcntl() locks. </p>
56
<p> You can also "play safe" and throw in <i>username</i>.lock files: </p>
20
<h2> Postfix support status for NFS </h2>
22
<p> What is the status of support for Postfix on NFS? The answer
23
is that Postfix itself is supported when you use NFS, but there is
24
no promise that an NFS-related problem will promptly receive a
25
Postfix workaround, or that a workaround will even be possible.
28
<p> That said, Postfix will in many cases work very well on NFS,
29
because Postfix implements a number of workarounds (see below).
30
Good NFS implementations seldom if ever give problems with Postfix,
31
so Wietse recommends that you spend your money wisely. </p>
33
<h2> Postfix file locking and NFS </h2>
35
<p> For the Postfix mail queue, it does not matter how well NFS
36
file locking works. The reason is that you cannot share Postfix
37
queues among multiple running Postfix instances. You can use NFS
38
to switch a Postfix mail queue from one NFS client to another one,
39
but only one NFS client can access a Postfix mail queue at any
40
particular point in time. </p>
42
<p> For mailbox file sharing with NFS, your options are to use
43
<b>fcntl</b> (kernel locks), <b>dotlock</b> (<i>username</i>.lock
44
files), to use both locking methods simultaneously, or to switch
45
to maildir format. The maildir format uses one file per message and
46
needs no file locking support in Postfix or in other mail software.
49
<p> Many sites that use mailbox format play safe and use both locking
50
methods simultaneously. </p>
54
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
61
55
<a href="postconf.5.html#virtual_mailbox_lock">virtual_mailbox_lock</a> = fcntl, dotlock
62
56
<a href="postconf.5.html#mailbox_delivery_lock">mailbox_delivery_lock</a> = fcntl, dotlock
66
<p> This is the combination that many applications end up using. </p>
60
<h2> Postfix NFS workarounds </h2>
62
<p> The list below summarizes the workarounds that exist for running
63
Postfix on NFS as of the middle of 2003. As a reminder, Postfix
64
itself is still supported when it runs on NFS, but there is no
65
promise that an NFS-related problem will promptly receive a Postfix
66
workaround, or that a workaround will even be possible. </p>
70
<li> <p> Problem: when renaming a file, the operation may succeed
71
but report an error anyway<sup>[1]</sup>. </p>
73
<p> Workaround: when rename(old, new) reports an error, Postfix
74
checks if the new name exists and the old name is gone. If the check
75
succeeds, Postfix assumes that the rename() operation completed
78
<li> <p> Problem: when creating a directory, the operation may succeed
79
but report an error anyway<sup>[1]</sup>. </p>
81
<p> Workaround: when mkdir(new) reports an EEXIST error, Postfix
82
checks if the new name resolves to a directory. If the check succeeds,
83
Postfix assumes that the mkdir() operation completed normally. </p>
85
<li> <p> Problem: when creating a hardlink to a file, the operation
86
may succeed but report an error anyway<sup>[1]</sup>. </p>
88
<p> Workaround: when link(old, new) fails, Postfix compares the
89
device and inode number of the old and new files. When the two files
90
are identical, Postfix assumes that the link() operation completed
93
<li> <p> Problem: when creating a dotlock (<i>username</i>.lock)
94
file, the operation may succeed but report an error anyway<sup>[1]</sup>.
97
<p> Workaround: in this case, the only safe action is to back off
98
and try again later. </p>
100
<li> <p> Problem: when a file server's "time of day" clock is not
101
synchronized with the client's "time of day" clock, email deliveries
102
are delayed by a minute or more. </p>
104
<p> Workaround: Postfix explicitly sets file time stamps to avoid
105
delays with new mail (Postfix uses "last modified" file time stamps
106
to decide when a queue file is ready for delivery). </p>
110
<p> <sup>[1]</sup> How can an operation succeed and report an error
113
<p> Suppose that an NFS server executes a client request successfully,
114
and that the server's reply to the client is lost. After some time
115
the client retransmits the request to the server. Normally, the
116
server remembers that it already completed the request (it keeps a
117
list of recently-completed requests and replies), and simply
118
retransmits the reply. </p>
120
<p> However, when the server has rebooted or when it has been very
121
busy, the server no longer remembers that it already completed the
122
request, and repeats the operation. This causes no problems with
123
file read/write requests (they contain a file offset and can therefore
124
be repeated safely), but fails with non-idempotent operations. For
125
example, when the server executes a retransmitted rename() request,
126
the server reports an ENOENT error because the old name does not
127
exist; and when the server executes a retransmitted link(), mkdir()
128
or create() request, the server reports an EEXIST error because the
129
name already exists. </p>
131
<p> Thus, successful, non-idempotent, NFS operations will report
132
false errors when the server reply is lost, the client retransmits
133
the request, and the server does not remember that it already
134
completed the request. </p>
added
removed
html/NFS_README.html
