On Wed, 2005-04-27 at 10:56 +0200, Thomas Wouters wrote:
On Wed, Apr 27, 2005 at 09:47:25AM +0200, dovecot.7.signal11@spamgourmet.com wrote:
We have NFS-mounted user directories which cause significant problems with stale file handles:
dovecot: IMAP(uid): fstat() failed with file /home/uid/mail/.imap/INBOX/dovecot.index.log: Stale NFS file handle
(a) why can't it just close the file and re-open ?
NFS has issues with files that are open on one client, and get deleted on another. UNIX systems require that files don't disappear while they are in use, but NFS is stateless and it simply can't know when a file is in use. The result is the 'stale NFS handle' kludge, which also prevents a simple close-and-open. Don't use index files on NFS disks.
This is actually a TODO item. Dovecot should be able to handle all ESTALE errors, but I just haven't implemented them. With dovecot.index.log handling code the ESTALE is an expected error with NFS because Dovecot rotates the log file continuously overwriting the existing one.
Actually the new code in CVS nowadays rotates .log file to .log.2 file, which should make this problem much more rare.
"First, the file did not disappear - the NFS is flaky under high load, that's all. Closing and re-opening the file would probably fix the issue, at least after the traffic spike."
Can this really happen with high NFS load, or is it just that Dovecot had more time to rotate its log files? I'm not sure if I can reliably fix the ESTALE problems if they happen randomly with the file actually being lost.
(b) is there a way to specify with the 'default_mail_env' (or in some other way) the location of **only** the indexes (and let dovecot autodetect all else?).
Haven't figured that one out myself either :)
Guess not. New configuration file code has split them to different settings though, that'll fix it. Now if I only could get all that code to work so I could commit it.. :)