Re: NFS Problem in Kernel 2.0.27: inode status not updated

Top Page
Delete this message
Reply to this message
Author: Piete Brooks
Date:  
To: Philip Hazel
CC: exim-users
Subject: Re: NFS Problem in Kernel 2.0.27: inode status not updated
>> Can any hitching post users (other than Linux -- are there any ?) comment on
>> whether hitching post locks work between different hosts (both NFS clients) ?
> I haven't turned off the use of lock files on the Central Unix Service,
> though of course Exim uses lockf locking as well. I don't know what all
> the various MUAs use, but we haven't had any complaints. Mail is
> delivered by either of two Solaris 2 systems into a partition that
> resides on an FAServer machine. So all access to mailboxes is via NFS.


As you say, you have *real* locking enabled as well.

But I did say *RELIABLY*

Sure, mail delivery will work 99.99% of the time *WITHOUT* locking,
and the other 0.01%, the user probably won't know that it failed !

99% of the time, there is no contention.
Of the 1% of the time when there is some coarse level of contention
(i.e. there is a point in time when the MTA is considering delivering and the
MUA is considering reading), 99% of the time there won't be a problem, as the
transactions will be serializable ...
In general, exim will do a single write to the user's mailbox.
If the MUA uses "rename and then process", unless there is a *LARGE* message,
the chances are that the message will be delivered normally with a small chance
of the write occuring *after* the read, and a smaller still chance of the last
read occurring before the last write has completed.
So it's likley that 99.99% will work correctly.
0.009% might fail completely, and not be detected at all.
0.0009% might result in a truncated message, which the user dooes not notice,
or puts down to sender error,
0.00009% where the user detects a truncated write, mutters under breath about
broken MTAs / MUAs,
0.000009% of truncated writes reported to the local postmaster, who mutters,
0.000001% of truncated writes reported to the MUA / MTA author !

OK, so the figures are made up (I suspect much less than 1% contention on big
MTAs !), but you get the drift -- no complaints does **NOT** mean that the
locking works !
For testing lockd style lock, I have a trivial perl script which takes out a
lock on a file. I then check that MUA and MTA both refuse to touch the mailbox.