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

On Tue, 31 Dec 1996, Piete Brooks wrote:

Piete.Brooks >2) locking between multiple systems (e.g. MTA and MUA)
Piete.Brooks >
Piete.Brooks >The first is a simple (IMHO) bug in the Linux NFS code (with fix in hand) such
Piete.Brooks >that even if *this* system just created a new link, the link count was not
Piete.Brooks >incremented.
Piete.Brooks >
Piete.Brooks >The second is a general problem when *REAL* locking (lockd isn't available
Piete.Brooks >for Linux -- if it were, we wouldn't be using hitching posts !) isn't available
Piete.Brooks >so that hitching posts are used.
Piete.Brooks >All systems concerned need to have accurate information, and not rely on so
Piete.Brooks >called "cache"s (actually hints with TTLs).

You are right. That is a big issue. Perhaps simply locking by creation
of the mbox.open file and checking the error code is more reliable?

I know that many people have already spent their time on figuring out a
reliable way to lock across NFS but maybe there is no way. We could try to
make linux NFS creat() call atomic (Perhaps it already is given the need
for reliable locks?) resulting in
a reliable locking with simply creating the lock file.

Linux NFS is currently in the revision process and there is an
experimental lockd available (does not work though ...)


--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5