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 23is that Postfix itself is supported when you use NFS, but there is 24no promise that an NFS-related problem will promptly receive a 25Postfix 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, 29because Postfix implements a number of workarounds (see below). 30Good NFS implementations seldom if ever give problems with Postfix, 31so 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 36file locking works. The reason is that you cannot share Postfix 37queues among multiple running Postfix instances. You can use NFS 38to switch a Postfix mail queue from one NFS client to another one, 39but only one NFS client can access a Postfix mail queue at any 40particular 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 44files), to use both locking methods simultaneously, or to switch 45to maildir format. The maildir format uses one file per message and 46needs 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 50methods 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 63Postfix on NFS as of the middle of 2003. As a reminder, Postfix 64itself is still supported when it runs on NFS, but there is no 65promise that an NFS-related problem will promptly receive a Postfix 66workaround, 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 71but report an error anyway<sup>[1]</sup>. </p> 72 73<p> Workaround: when rename(old, new) reports an error, Postfix 74checks if the new name exists and the old name is gone. If the check 75succeeds, Postfix assumes that the rename() operation completed 76normally. </p> 77 78<li> <p> Problem: when creating a directory, the operation may succeed 79but report an error anyway<sup>[1]</sup>. </p> 80 81<p> Workaround: when mkdir(new) reports an EEXIST error, Postfix 82checks if the new name resolves to a directory. If the check succeeds, 83Postfix assumes that the mkdir() operation completed normally. </p> 84 85<li> <p> Problem: when creating a hardlink to a file, the operation 86may succeed but report an error anyway<sup>[1]</sup>. </p> 87 88<p> Workaround: when link(old, new) fails, Postfix compares the 89device and inode number of the old and new files. When the two files 90are identical, Postfix assumes that the link() operation completed 91normally. </p> 92 93<li> <p> Problem: when creating a dotlock (<i>username</i>.lock) 94file, 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 98and try again later. </p> 99 100<li> <p> Problem: when a file server's "time of day" clock is not 101synchronized with the client's "time of day" clock, email deliveries 102are delayed by a minute or more. </p> 103 104<p> Workaround: Postfix explicitly sets file time stamps to avoid 105delays with new mail (Postfix uses "last modified" file time stamps 106to 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 111anyway? </p> 112 113<p> Suppose that an NFS server executes a client request successfully, 114and that the server's reply to the client is lost. After some time 115the client retransmits the request to the server. Normally, the 116server remembers that it already completed the request (it keeps a 117list of recently-completed requests and replies), and simply 118retransmits the reply. </p> 119 120<p> However, when the server has rebooted or when it has been very 121busy, the server no longer remembers that it already completed the 122request, and repeats the operation. This causes no problems with 123file read/write requests (they contain a file offset and can therefore 124be repeated safely), but fails with non-idempotent operations. For 125example, when the server executes a retransmitted rename() request, 126the server reports an ENOENT error because the old name does not 127exist; and when the server executes a retransmitted link(), mkdir() 128or create() request, the server reports an EEXIST error because the 129name already exists. </p> 130 131<p> Thus, successful, non-idempotent, NFS operations will report 132false errors when the server reply is lost, the client retransmits 133the request, and the server does not remember that it already 134completed the request. </p> 135 136</body> 137</html> 138