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=utf-8"> 11<link rel='stylesheet' type='text/css' href='postfix-doc.css'> 12 13</head> 14 15<body> 16 17<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix and NFS</h1> 18 19<hr> 20 21<h2> Postfix support status for NFS </h2> 22 23<p> What is the status of support for Postfix on NFS? The answer 24is that Postfix itself is supported when you use NFS, but there is 25no promise that an NFS-related problem will promptly receive a 26Postfix workaround, or that a workaround will even be possible. 27</p> 28 29<p> That said, Postfix will in many cases work very well on NFS, 30because Postfix implements a number of workarounds (see below). 31Good NFS implementations seldom if ever give problems with Postfix, 32so Wietse recommends that you spend your money wisely. </p> 33 34<h2> Postfix file locking and NFS </h2> 35 36<p> For the Postfix mail queue, it does not matter how well NFS 37file locking works. The reason is that you cannot share Postfix 38queues among multiple running Postfix instances. You can use NFS 39to switch a Postfix mail queue from one NFS client to another one, 40but only one NFS client can access a Postfix mail queue at any 41particular point in time. </p> 42 43<p> For mailbox file sharing with NFS, your options are to use 44<b>fcntl</b> (kernel locks), <b>dotlock</b> (<i>username</i>.lock 45files), to use both locking methods simultaneously, or to switch 46to maildir format. The maildir format uses one file per message and 47needs no file locking support in Postfix or in other mail software. 48</p> 49 50<p> Many sites that use mailbox format play safe and use both locking 51methods simultaneously. </p> 52 53<blockquote> 54<pre> 55/etc/postfix/main.cf: 56 virtual_mailbox_lock = fcntl, dotlock 57 mailbox_delivery_lock = fcntl, dotlock 58</pre> 59</blockquote> 60 61<h2> Postfix NFS workarounds </h2> 62 63<p> The list below summarizes the workarounds that exist for running 64Postfix on NFS as of the middle of 2003. As a reminder, Postfix 65itself is still supported when it runs on NFS, but there is no 66promise that an NFS-related problem will promptly receive a Postfix 67workaround, or that a workaround will even be possible. </p> 68 69<ul> 70 71<li> <p> Problem: when renaming a file, the operation may succeed 72but report an error anyway<sup>[1]</sup>. </p> 73 74<p> Workaround: when rename(old, new) reports an error, Postfix 75checks if the new name exists and the old name is gone. If the check 76succeeds, Postfix assumes that the rename() operation completed 77normally. </p> 78 79<li> <p> Problem: when creating a directory, the operation may succeed 80but report an error anyway<sup>[1]</sup>. </p> 81 82<p> Workaround: when mkdir(new) reports an EEXIST error, Postfix 83checks if the new name resolves to a directory. If the check succeeds, 84Postfix assumes that the mkdir() operation completed normally. </p> 85 86<li> <p> Problem: when creating a hardlink to a file, the operation 87may succeed but report an error anyway<sup>[1]</sup>. </p> 88 89<p> Workaround: when link(old, new) fails, Postfix compares the 90device and inode number of the old and new files. When the two files 91are identical, Postfix assumes that the link() operation completed 92normally. </p> 93 94<li> <p> Problem: when creating a dotlock (<i>username</i>.lock) 95file, the operation may succeed but report an error anyway<sup>[1]</sup>. 96</p> 97 98<p> Workaround: in this case, the only safe action is to back off 99and try again later. </p> 100 101<li> <p> Problem: when a file server's "time of day" clock is not 102synchronized with the client's "time of day" clock, email deliveries 103are delayed by a minute or more. </p> 104 105<p> Workaround: Postfix explicitly sets file time stamps to avoid 106delays with new mail (Postfix uses "last modified" file time stamps 107to decide when a queue file is ready for delivery). </p> 108 109</ul> 110 111<p> <sup>[1]</sup> How can an operation succeed and report an error 112anyway? </p> 113 114<p> Suppose that an NFS server executes a client request successfully, 115and that the server's reply to the client is lost. After some time 116the client retransmits the request to the server. Normally, the 117server remembers that it already completed the request (it keeps a 118list of recently-completed requests and replies), and simply 119retransmits the reply. </p> 120 121<p> However, when the server has rebooted or when it has been very 122busy, the server no longer remembers that it already completed the 123request, and repeats the operation. This causes no problems with 124file read/write requests (they contain a file offset and can therefore 125be repeated safely), but fails with non-idempotent operations. For 126example, when the server executes a retransmitted rename() request, 127the server reports an ENOENT error because the old name does not 128exist; and when the server executes a retransmitted link(), mkdir() 129or create() request, the server reports an EEXIST error because the 130name already exists. </p> 131 132<p> Thus, successful, non-idempotent, NFS operations will report 133false errors when the server reply is lost, the client retransmits 134the request, and the server does not remember that it already 135completed the request. </p> 136 137</body> 138</html> 139
