Perhaps I misinterpreted this: http://www.washington.edu/pine/pine-info/2004.04/msg00031.html "If you only access mail through IMAP, file locking is not needed." -- I thought maybe this was in reference to pine, but the wording isn't clear. I am glad to hear that reason doesn't go out the window with IMAP
I've just read that message. It is inaccurate on several issues. Please disregard it.
http://www.washington.edu/imap/documentation/locking.txt.html The c-client file locking documentation says "If the mail file is NFS-mounted then flock() locking is a silent no-op." Is that what would occur in the situation I described? I don't quite understand what "silent no-op" means either.
It means that flock() will succeed, having done nothing. Thus, the application will think that there is an flock() lock, but in fact there isn't. Consequently, any assumptions that depend upon there being an flock() lock are invalid.
are cutsiepop and sendmail two of programs that you refer to as "non c-type applications"
I do not know what "cutsiepop" is. Nor do I recognize the phrase "non c-type applications".
The documentation also says that c-client uses flock on SystemV systems.
No it does not. SystemV systems do not have flock(). They have fcntl() locking.
Is this what happens on Linux (Redhat 9)?
flock() is used on Linux().
If what I understand about Lustre is correct, then using Lustre would fix the NFS locking problem [snip]
I have heard many times over a period of over a decade about how "this time for sure" the problems of remote flock() and file synchronization with remote file servers were fixed. Each and every time, the hopes and expectations were bitterly dashed. UW itself wasted a few years on this fantasy before abandoning it.
I have not heard of Lustre before, but I remain highly skeptical.
The system in question has been implemented with NFS already because 1) of the small number of users we were initially required to support 2) management has a desire to implement this design to make the data servers fully extensible without fragmenting the user space.
Has your management considered that they have a single point of failure (the NFS server) in their configuration; and that when that point fails your entire facility is dead?
When you say each user gets a separate server do you mean each individual account?
Yes.
and by server do you mean server application or complete server hardware?
Server system. Hardware.
I'm assuming from what I've read (admittedly from the same source) that there is a way to configure IMAP whether it uses flock or a lock file.
No, there is not. IMAP uses both. It must use both.
I do know that when IMAP is run on a separate server, and accesses the mail box over NFS it is slow, when it is put directly on the server that has the data it runs much faster
This is exactly what I expect. NFS is evil for IMAP. Don't use it.
but seems to block POP and SMTP almost entirely.
What do you mean by this?
What I am looking for is what would be required to allow all the data to reside in one [system] that would have the capacity to appear as one mount point
Bad idea. Single point of failure. Single bottleneck for I/O.
Distributed services are good.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
