> Date: Mon, 3 May 2010 10:17:06 -0700 (PDT) > From: Mark Crispin <mrc...@panda.com> > > > 1) If mbox file's mtime and size match > > Perhaps that works better today than 20 years ago. Back then, you could > not trust mtime to reflect reality in any reasonable way particularly > when NFS was involved. The most common circumstance is that mtime simply > wasn't updated. This happened even with local files. The explanation > that I got at the time was that it was somehow "inefficient" to keep the > mtime reliably up to date.
nfs file attribute changes are always at least three seconds out of date as witnessed between a process running on a client and process running on the server and possibly much longer between two processes running on two clients, because of the way the caching/pipelining works. this got a LOT better with the nqlease stuff back in 1993 but i don't know if that's in every nfs implementation even today. > > 3) If file size decreases, assume expunged messages -> re-read entire > > mbox file. > > This is reasonable if you have UIDs in the file (which of course is the > case today) since that allows you to resynchronize nicely. In fact, > that's excactly how mix resynchronization works. i note that there are no X-UID headers in MH. how much would it help uw-imap's MH performance/correctness if these headers were added by inc(1) and other file-writing functions in MH/NMH? > > It should work pretty well as long as fcntl locking is used, because it > > reliably also clears NFS caches (hoping of course that nfs.lockd itself > > doesn't break). > > That's a big hope; and in my experience a futile one. I used to be able > to tell when SUN broke my test for NFS (and thus not use fcntl locks) > when I would get reports of cluster-wide hangs on Solaris boxes. these days almost nobody still accesses the system mailbox by NFS, nor access user mailboxes on NFS from more than one client at the same time. so, dovecot's assumptions are pretty reasonable. compile-time options in uw-imapd that changed its assumptions in this way would be popular. _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
