Adding upstream version 3.5.24.upstream/3.5.24upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 102 insertions, 0 deletions

diff --git a/README_FILES/NFS_README b/README_FILES/NFS_README
new file mode 100644
index 0000000..60d0578
--- /dev/null
+++ b/README_FILES/NFS_README
@@ -0,0 +1,102 @@
+PPoossttffiixx aanndd NNFFSS
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx ssuuppppoorrtt ssttaattuuss ffoorr NNFFSS
+
+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.
+
+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.
+
+PPoossttffiixx ffiillee lloocckkiinngg aanndd NNFFSS
+
+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.
+
+For mailbox file sharing with NFS, your options are to use ffccnnttll (kernel
+locks), ddoottlloocckk (username.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.
+
+Many sites that use mailbox format play safe and use both locking methods
+simultaneously.
+
+    /etc/postfix/main.cf:
+        virtual_mailbox_lock = fcntl, dotlock
+        mailbox_delivery_lock = fcntl, dotlock
+
+PPoossttffiixx NNFFSS wwoorrkkaarroouunnddss
+
+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.
+
+  * Problem: when renaming a file, the operation may succeed but report an
+    error anyway[1].
+
+    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.
+
+  * Problem: when creating a directory, the operation may succeed but report an
+    error anyway[1].
+
+    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.
+
+  * Problem: when creating a hardlink to a file, the operation may succeed but
+    report an error anyway[1].
+
+    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.
+
+  * Problem: when creating a dotlock (username.lock) file, the operation may
+    succeed but report an error anyway[1].
+
+    Workaround: in this case, the only safe action is to back off and try again
+    later.
+
+  * 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.
+
+    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).
+
+[1] How can an operation succeed and report an error anyway?
+
+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.
+
+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.
+
+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.
+