postfix-master/NFS_README.html

   1 <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
   2         "http://www.w3.org/TR/html4/loose.dtd">
   3
   4 <html>
   5
   6 <head>
   7
   8 <title>Postfix and NFS</title>
   9
  10 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
  11
  12 </head>
  13
  14 <body>
  15
  16 <h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix and NFS</h1>
  17
  18 <hr>
  19
  20 <h2> Postfix support status for NFS </h2>
  21
  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.
  26 </p>
  27
  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>
  32
  33 <h2> Postfix file locking and NFS </h2>
  34
  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>
  41
  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.
  47 </p>
  48
  49 <p> Many sites that use mailbox format play safe and use both locking
  50 methods simultaneously. </p>
  51
  52 <blockquote>
  53 <pre>
  54 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
  55     <a href="postconf.5.html#virtual_mailbox_lock">virtual_mailbox_lock</a> = fcntl, dotlock
  56     <a href="postconf.5.html#mailbox_delivery_lock">mailbox_delivery_lock</a> = fcntl, dotlock
  57 </pre>
  58 </blockquote>
  59
  60 <h2> Postfix NFS workarounds </h2>
  61
  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>
  67
  68 <ul>
  69
  70 <li> <p> Problem: when renaming a file, the operation may succeed
  71 but report an error anyway<sup>[1]</sup>. </p>
  72
  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
  76 normally.  </p>
  77
  78 <li> <p> Problem: when creating a directory, the operation may succeed
  79 but report an error anyway<sup>[1]</sup>. </p>
  80
  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>
  84
  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>
  87
  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
  91 normally. </p>
  92
  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>.
  95 </p>
  96
  97 <p> Workaround: in this case, the only safe action is to back off
  98 and try again later.  </p>
  99
 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>
 103
 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>
 107
 108 </ul>
 109
 110 <p> <sup>[1]</sup> How can an operation succeed and report an error
 111 anyway? </p>
 112
 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>
 119
 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>
 130
 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>
 135
 136 </body>
 137 </html>