On 3.5.2010, at 20.17, Mark Crispin wrote: > On Mon, 3 May 2010, Timo Sirainen wrote: >> 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. > > UW imapd doesn't trust mtime for any purpose, and takes a big hurt for > that.
It's still true that NFS usually has attribute caching enabled, and mtime doesn't necessarily update (I think default is something like max. wait of 60 seconds after change). But that's what I tried to prevent with my attempts to force NFS clients to flush their caches. This mtime flushing actually works pretty easily in all modern OSes: just open and close the file and then stat/fstat. Other types of NFS cache flushes work less well. And people don't like to disable the caching, since it increases load by 10x in the NFS server. >> 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. > > Back in the day, there was no good way for UW imapd to resynchronize in > this case. Oh, it could have done an MD5 checksum of each message, but... Yeah, I actually also fallback to MD5 of a few specific headers if X-UID: headers haven't been written to disk yet. >> Also as long as Dovecot is the only thing modifying the mbox file, state >> is shared via index files, so 1) check always succeeds and the >> performance stays good. > > Those three things: being able to trust mtime, index files, and the > ability to resynchronize, are the big things in Dovecot. For various > reasons those very things weren't feasible in the day (now nearly 20 years > ago) when UW IMAP's mbox code was first written; and when it became > feasible it was done in more modern formats (first mbx, then mix). The annoying thing with Dovecot's mbox optimizations is that they're pretty complex and I'm sure there are bugs there. Also it's difficult to sometimes figure out if something is a bug or just a side effect of some other software modifying the mbox, possibly with incompatible locking rules, etc.. So I'm kind of hoping people would stop using mbox. :) Or maybe I could at least simplify the code._______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
