diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 01:46:30 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 01:46:30 +0000 |
| commit | b5896ba9f6047e7031e2bdee0622d543e11a6734 (patch) | |
| tree | fd7b460593a2fee1be579bec5697e6d887ea3421 /html/NFS_README.html | |
| parent | Initial commit. (diff) | |
| download | postfix-2f07919848e7bd4a084699d26e8821e3a00696d9.tar.xz postfix-2f07919848e7bd4a084699d26e8821e3a00696d9.zip | |
Adding upstream version 3.4.23.upstream/3.4.23upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'html/NFS_README.html')
| -rw-r--r-- | html/NFS_README.html | 137 |
1 files changed, 137 insertions, 0 deletions
diff --git a/html/NFS_README.html b/html/NFS_README.html new file mode 100644 index 0000000..fdbd0fd --- /dev/null +++ b/html/NFS_README.html @@ -0,0 +1,137 @@ +<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" + "http://www.w3.org/TR/html4/loose.dtd"> + +<html> + +<head> + +<title>Postfix and NFS</title> + +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> + +</head> + +<body> + +<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix and NFS</h1> + +<hr> + +<h2> Postfix support status for NFS </h2> + +<p> What is the status of support for Postfix on NFS? The answer +is that Postfix itself is supported when you use NFS, but there is +no promise that an NFS-related problem will promptly receive a +Postfix workaround, or that a workaround will even be possible. +</p> + +<p> That said, Postfix will in many cases work very well on NFS, +because Postfix implements a number of workarounds (see below). +Good NFS implementations seldom if ever give problems with Postfix, +so Wietse recommends that you spend your money wisely. </p> + +<h2> Postfix file locking and NFS </h2> + +<p> For the Postfix mail queue, it does not matter how well NFS +file locking works. The reason is that you cannot share Postfix +queues among multiple running Postfix instances. You can use NFS +to switch a Postfix mail queue from one NFS client to another one, +but only one NFS client can access a Postfix mail queue at any +particular point in time. </p> + +<p> For mailbox file sharing with NFS, your options are to use +<b>fcntl</b> (kernel locks), <b>dotlock</b> (<i>username</i>.lock +files), to use both locking methods simultaneously, or to switch +to maildir format. The maildir format uses one file per message and +needs no file locking support in Postfix or in other mail software. +</p> + +<p> Many sites that use mailbox format play safe and use both locking +methods simultaneously. </p> + +<blockquote> +<pre> +/etc/postfix/<a href="postconf.5.html">main.cf</a>: + <a href="postconf.5.html#virtual_mailbox_lock">virtual_mailbox_lock</a> = fcntl, dotlock + <a href="postconf.5.html#mailbox_delivery_lock">mailbox_delivery_lock</a> = fcntl, dotlock +</pre> +</blockquote> + +<h2> Postfix NFS workarounds </h2> + +<p> The list below summarizes the workarounds that exist for running +Postfix on NFS as of the middle of 2003. As a reminder, Postfix +itself is still supported when it runs on NFS, but there is no +promise that an NFS-related problem will promptly receive a Postfix +workaround, or that a workaround will even be possible. </p> + +<ul> + +<li> <p> Problem: when renaming a file, the operation may succeed +but report an error anyway<sup>[1]</sup>. </p> + +<p> Workaround: when rename(old, new) reports an error, Postfix +checks if the new name exists and the old name is gone. If the check +succeeds, Postfix assumes that the rename() operation completed +normally. </p> + +<li> <p> Problem: when creating a directory, the operation may succeed +but report an error anyway<sup>[1]</sup>. </p> + +<p> Workaround: when mkdir(new) reports an EEXIST error, Postfix +checks if the new name resolves to a directory. If the check succeeds, +Postfix assumes that the mkdir() operation completed normally. </p> + +<li> <p> Problem: when creating a hardlink to a file, the operation +may succeed but report an error anyway<sup>[1]</sup>. </p> + +<p> Workaround: when link(old, new) fails, Postfix compares the +device and inode number of the old and new files. When the two files +are identical, Postfix assumes that the link() operation completed +normally. </p> + +<li> <p> Problem: when creating a dotlock (<i>username</i>.lock) +file, the operation may succeed but report an error anyway<sup>[1]</sup>. +</p> + +<p> Workaround: in this case, the only safe action is to back off +and try again later. </p> + +<li> <p> Problem: when a file server's "time of day" clock is not +synchronized with the client's "time of day" clock, email deliveries +are delayed by a minute or more. </p> + +<p> Workaround: Postfix explicitly sets file time stamps to avoid +delays with new mail (Postfix uses "last modified" file time stamps +to decide when a queue file is ready for delivery). </p> + +</ul> + +<p> <sup>[1]</sup> How can an operation succeed and report an error +anyway? </p> + +<p> Suppose that an NFS server executes a client request successfully, +and that the server's reply to the client is lost. After some time +the client retransmits the request to the server. Normally, the +server remembers that it already completed the request (it keeps a +list of recently-completed requests and replies), and simply +retransmits the reply. </p> + +<p> However, when the server has rebooted or when it has been very +busy, the server no longer remembers that it already completed the +request, and repeats the operation. This causes no problems with +file read/write requests (they contain a file offset and can therefore +be repeated safely), but fails with non-idempotent operations. For +example, when the server executes a retransmitted rename() request, +the server reports an ENOENT error because the old name does not +exist; and when the server executes a retransmitted link(), mkdir() +or create() request, the server reports an EEXIST error because the +name already exists. </p> + +<p> Thus, successful, non-idempotent, NFS operations will report +false errors when the server reply is lost, the client retransmits +the request, and the server does not remember that it already +completed the request. </p> + +</body> +</html> |