On Tue, 4 May 2010, Paul Vixie wrote:
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.
The problem is even worse than the delay. Updates over NFS occur out of order; or at least once upon a time they did. This would result in the data and the inode being completely inconsistent with each other. I forget what it was that would provoke NFS into this behavior, but I run up against it all the time. Once this state occurred for that file, it seemed that nothing short of swamping the buffer cache would clear it. Not even the normal NFS open/close/stat trick was good enough. It was quite a shock for me, coming from an environment in which even network filesystems were guaranteed to maintain full synchronization.
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 would help correctness, as it would remedy the problem caused by mh compact. UIDs can't be renumbered, but that's what compact does to the file numbers. UW IMAP uses the file numbers as non-persistent UIDs, which unlike persistent UIDs are useless for synchronization. Unfortunately, it would greatly hurt performance. It would require that all the files be read at open time in order to get the UIDs. A synchronization step would also do the same thing. A better implementation would use an index file that maps between a UID and a device/inode number of the file. To open and synchronize, you stat() all the files and then correlate that with the index to build a map. This would also identify newly-added and expunged messages. All this requires is an atomic snapshot of the directory. But, as the more honest maildir developers will tell you, that's the rub; there's a timing race that can occur with file renames while you are reading a directory... In my opinion, it's better to use data formats designed for the task at hand, rather than ever-escalating steps to get legacy formats to do what they were never designed nor intended to do. Remember, when I first designed IMAP, a big criticism was that it was "impossible" for more than one agent to consume a mailbox at the same time, yet this funny IMAP protocol was claiming to offer that service.
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 the world today has finally accepted my advice from 20+ years ago. I'm surprised, though; since "do everything via NFS" was the SUN corporate religion (maybe Oracle has disestablished it). I recognized the absurdity of layering a NAS (IMAP) on top of a NAS (NFS) early on, but SUN (and IBM) insisted for a long time that the right way to do IMAP was to have a cluster of IMAP servers consuming an NFS server. Maybe in another 20+ years people will accept my advice on how to do IMAP clients. The designers of webmails already follow those principles.
so, dovecot's assumptions are pretty reasonable. compile-time options in uw-imapd that changed its assumptions in this way would be popular.
UW IMAP is a dead project. If I ever do anything like that, it would be in Panda IMAP. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
