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

Alan Cox (
Wed, 1 Jan 1997 18:30:43 +0000 (GMT)

> What the application does if the filesystem does not support hardlinks,
> is another matter (in my case, the application tries to take some
> other adequate but far from perfect measures) and completely beside the
> point. We're only discussing the problem where the NFS server is in fact
> running UNIX.

All the worlds a VAX syndrome again. Your program should not be making
that assumption. Users aren't generally happy when they change their
NFS server and a pile of junk applications fail.

> If there is only one UNIX NFS-server, and there is only one UNIX NFS-client,
> then the client OS *must* be able to get link() and stat() right in *all*
> cases except for case when the NFS server should crash between having performed

But then you don't need your locking scheme do you, so you've just reduced
the problem to pointlessness.

> a successful link() and reporting back success to the client.
> The stat() call should return accurate data in *all* cases. The current
> caching implementation in Linux does not guarantee this.

For any case where there are two or more clients it cannot return accurate
data reliably in any case.

> I'm not saying that it has to support everything directly. But the
> OS (Linux in this case) *must* emulate everything to the best of its
> abilities (at least for the most simple case where it is the only

Not in the NFS specification. It would be nice of it to provide you
with Unix like link counts , but you couldn't ever use them for anything
or assume they were valid except in the only client case, which you don't
need it for anyway.

> but that's not the point here). Forgetting to increase the link count or
> not flushing the cache is a blatant error.

Nope its not in the NFS specification. Stop treating NFS like a Unix file
system and you'll get a lot further.

NFS makes NO guarantees in any situation about supporting unix link counts,
about supporting POSIX semantics, about caching coherency, about operation
order or anything else.

> >Even altering the cached attributes will not save you as your cache
> >may be invalid anyway.
> Not if you're the only client. I would expect *every* UNIX implementation
> to get at least *that* right.

Define 'right'. NFS isnt a unix specific file system so your notion of right
is a bit strange. Since an operation can be indefinitely delayed your
"only client" is actually "only client who has ever made requests on that
inode since the beginning of the universe".