external/ibm-public/postfix/dist/README_FILES/NFS_README

   1 P\bPo\bos\bst\btf\bfi\bix\bx a\ban\bnd\bd N\bNF\bFS\bS
   2
   3 -------------------------------------------------------------------------------
   4
   5 P\bPo\bos\bst\btf\bfi\bix\bx s\bsu\bup\bpp\bpo\bor\brt\bt s\bst\bta\bat\btu\bus\bs f\bfo\bor\br N\bNF\bFS\bS
   6
   7 What is the status of support for Postfix on NFS? The answer is that Postfix
   8 itself is supported when you use NFS, but there is no promise that an NFS-
   9 related problem will promptly receive a Postfix workaround, or that a
  10 workaround will even be possible.
  11
  12 That said, Postfix will in many cases work very well on NFS, because Postfix
  13 implements a number of workarounds (see below). Good NFS implementations seldom
  14 if ever give problems with Postfix, so Wietse recommends that you spend your
  15 money wisely.
  16
  17 P\bPo\bos\bst\btf\bfi\bix\bx f\bfi\bil\ble\be l\blo\boc\bck\bki\bin\bng\bg a\ban\bnd\bd N\bNF\bFS\bS
  18
  19 For the Postfix mail queue, it does not matter how well NFS file locking works.
  20 The reason is that you cannot share Postfix queues among multiple running
  21 Postfix instances. You can use NFS to switch a Postfix mail queue from one NFS
  22 client to another one, but only one NFS client can access a Postfix mail queue
  23 at any particular point in time.
  24
  25 For mailbox file sharing with NFS, your options are to use f\bfc\bcn\bnt\btl\bl (kernel
  26 locks), d\bdo\bot\btl\blo\boc\bck\bk (username.lock files), to use both locking methods
  27 simultaneously, or to switch to maildir format. The maildir format uses one
  28 file per message and needs no file locking support in Postfix or in other mail
  29 software.
  30
  31 Many sites that use mailbox format play safe and use both locking methods
  32 simultaneously.
  33
  34     /etc/postfix/main.cf:
  35         virtual_mailbox_lock = fcntl, dotlock
  36         mailbox_delivery_lock = fcntl, dotlock
  37
  38 P\bPo\bos\bst\btf\bfi\bix\bx N\bNF\bFS\bS w\bwo\bor\brk\bka\bar\bro\bou\bun\bnd\bds\bs
  39
  40 The list below summarizes the workarounds that exist for running Postfix on NFS
  41 as of the middle of 2003. As a reminder, Postfix itself is still supported when
  42 it runs on NFS, but there is no promise that an NFS-related problem will
  43 promptly receive a Postfix workaround, or that a workaround will even be
  44 possible.
  45
  46   * Problem: when renaming a file, the operation may succeed but report an
  47     error anyway[1].
  48
  49     Workaround: when rename(old, new) reports an error, Postfix checks if the
  50     new name exists and the old name is gone. If the check succeeds, Postfix
  51     assumes that the rename() operation completed normally.
  52
  53   * Problem: when creating a directory, the operation may succeed but report an
  54     error anyway[1].
  55
  56     Workaround: when mkdir(new) reports an EEXIST error, Postfix checks if the
  57     new name resolves to a directory. If the check succeeds, Postfix assumes
  58     that the mkdir() operation completed normally.
  59
  60   * Problem: when creating a hardlink to a file, the operation may succeed but
  61     report an error anyway[1].
  62
  63     Workaround: when link(old, new) fails, Postfix compares the device and
  64     inode number of the old and new files. When the two files are identical,
  65     Postfix assumes that the link() operation completed normally.
  66
  67   * Problem: when creating a dotlock (username.lock) file, the operation may
  68     succeed but report an error anyway[1].
  69
  70     Workaround: in this case, the only safe action is to back off and try again
  71     later.
  72
  73   * Problem: when a file server's "time of day" clock is not synchronized with
  74     the client's "time of day" clock, email deliveries are delayed by a minute
  75     or more.
  76
  77     Workaround: Postfix explicitly sets file time stamps to avoid delays with
  78     new mail (Postfix uses "last modified" file time stamps to decide when a
  79     queue file is ready for delivery).
  80
  81 [1] How can an operation succeed and report an error anyway?
  82
  83 Suppose that an NFS server executes a client request successfully, and that the
  84 server's reply to the client is lost. After some time the client retransmits
  85 the request to the server. Normally, the server remembers that it already
  86 completed the request (it keeps a list of recently-completed requests and
  87 replies), and simply retransmits the reply.
  88
  89 However, when the server has rebooted or when it has been very busy, the server
  90 no longer remembers that it already completed the request, and repeats the
  91 operation. This causes no problems with file read/write requests (they contain
  92 a file offset and can therefore be repeated safely), but fails with non-
  93 idempotent operations. For example, when the server executes a retransmitted
  94 rename() request, the server reports an ENOENT error because the old name does
  95 not exist; and when the server executes a retransmitted link(), mkdir() or
  96 create() request, the server reports an EEXIST error because the name already
  97 exists.
  98
  99 Thus, successful, non-idempotent, NFS operations will report false errors when
 100 the server reply is lost, the client retransmits the request, and the server
 101 does not remember that it already completed the request.
 102