On Mar 3, 2005, at 4:10 PM, John H. Robinson, IV wrote:
Andrew P. Lentvorski, Jr. wrote:
On Mar 2, 2005, at 11:35 PM, John H. Robinson, IV wrote:
Why? 1) The *only* NFS safe mailbox, PERIOD....5) No locking, no corruption.
I believe that these two are both *false*.
You have two systems, system A and system B. system A exports the mailspool, and system B mounts it. System A uses flock, and system b uses fcntl. Both want to update the mailspool at the same time. System A gets the flock, and system B gets the fcntl. BAM! Corrupted mailspool. Oops. Ah well, there is always backups.
Huh? How do both locks grant? The rpc.lockd must seize a hardware flock before granting the fcntl onto the network. Only one lock grants.
On Solaris, the rpc.lockd on system A will seize an flock on the hardware file which corresponds to the fcntl request from system B before granting the fcntl lock to system B. Solaris is intelligent about this, it will only seize the same size flock as the fcntl.
FreeBSD cheats. rpc.lockd seizes an flock on the entire file on system A and then parcels out the fcntl partial locks to system B. While this can cause more contention for the file, it never allows the hardware to corrupt the underlying file.
I know this for a fact. I wrote the code to do this. Go check the FreeBSD commit logs for rpc.lockd for version 5.X.
NFS mailspools work *just fine* under Solaris and FreeBSD. In fact, my main beta tester was a university with 12,000+ mboxes. I assure you that if there was a capacity for corruption, he would have hit it.
Oh, you meant on the broken implementation of NFS on Linux? Sorry, you
are out of luck. Actually, that may be an unfair accusation, I haven't
looked an NFS on Linux in about 2 years.
Nope. Nothing to do with Linux.
Actually, from your description, everything to do with Linux.
False. There is no locking, period. No delivery agent will ever try to write to the same file at the same time. This is why you don't need locks. Please see http://cr.yp.to/proto/maildir.html for a complete description.
Okay, so the delivery agent will never try to write to the same file at the same time. Other things can (and do). rsync attempting to copy an active maildir corrupts very nicely (been there, done that). rsync works very nicely even in the face of active mbox files and spools because it obeys the locks.
Shrug. You can abuse technology in many different ways.
I know, I know, your experience tells you otherwise. Yes, I agree: mbox is relatively safe over NFS. For years I have used mbox over NFS. Never had a problem. This does not mean I never will.
If you are on Solaris or FreeBSD, you never will.
Both formats need to die and should be replaced by something better.
Such as? What features would it have? What would it not have? Ideas!
Fast partial indexing (a la Mail.app for OS X) Store metadata out of band (or at least strictly syntax delimited) UTF-8 indexing and encoding Attachment handling (ability to store attachments offline/indexably)
-a
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
