Here is the official answer from the author of the NFS code in Linux.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
---------- Forwarded message ----------
Date: Tue, 31 Dec 1996 02:45:23 +0100
From: Olaf Kirch <okir@???>
To: linux-kernel@???
Cc: Christoph Lameter <clameter@???>
Subject: Re: NFS Problem in Kernel 2.0.27: inode status not updated
On Sat, 28 Dec 1996 10:25:29 PST, Christoph Lameter wrote:
> It first opens a lockfile with a unique name and then links that one
> to the classic /var/spool/mail/username.lock lockfile. Then it checks the
> number of links on that file. If there are two then the lock is
> successful. Problem is Linux fstat call always returns 1 for the number of
> links even though a link() was done immediately prior.
There is nothing in the NFS spec that requires the client to update its
cached link count[*]. So I would assume the author's claim means that this
locking technique `works better over NFS on the systems I tested it on.'
Nevertheless, I guess I'll have to support this in the upcoming NFS
code... For the time being, I suggest exim users apply the following
patch to fs/nfs/dir.c, function nfs_link:
-------- fake patch -----
nfs_lookup_cache_remove(dir, oldinode, NULL);
+ NFS_CACHEINV(oldinode);
iput(oldinode);
-------------------------
IMHO, mounting your mail spool with the noac mount option is not a
very good idea.
Olaf
[*] The NFS spec is deliberately vague about how and to which extent
the client caches information. Vague being an overstatement here.
For those interested, the bare-bones protocol spec is available as
RFC 1094. There's also a (fairly expensive) specification available
from X/Open that also discusses some implementation issues as well as
the side effects on various system calls and utility programs. Some
information about current implementation practice can also be found in
the NFSv3 spec (available as RFC, and as postscript file all over the
net--archie for nfsv3.ps).
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@??? | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger okir@???.
