Having a brief look at the 2.1 nfs server code lets me suspect that there
will be the same problem.
The basic problem is (if I got it right) the following:
The nfs server composes the nfs file handle of the path name and the
inode number and some other stuff.
Well, when the client accesses a file, it uses "struct
inode". Normally there is only one inode for each occurance of a
multiply hard linked file. This makes life much easier for local file
systems.
Now, to access a file via NFS, the client has to use the nfs file
handle. There is only a single nfs file handle per inode. And now
comes the problem: the nfs file handle depends on the path name, but
the inode does NOT depend on the path name. This is the same with
2.1.* NFS and with the old user level nfsd.
Therefore, there will always be problems: the inode on the client will
always contain the last updated nfs file handle for it. But if one
occurance of a multiply linked file is unlinked, this might be the
path that corresponds to the nfs remote file handle, and therefore the
server responds with an -ESTALE error.
MMh. I haven't read any NFS specs yet, but looking at the
implementation of the new kernel level nfsd and the old user level
nfsd I suspect that the nfs server grants access to file names, not to
inodes. I don't know anything of the requirements. Somewhere I had
found the nfs3 specs on ftp.funet.fi, didn't read them yet.
IMHO: I can't tell whether the nfs server implementation is buggy or
the NFS client implementation is buggy, but they cannot go together
w.r.t. multiply linked files. It just CANNOT work this way.
The client accesses files with the inode, the server only looks at the
path-name, i.e. provides one unique nfs file handle for each path name.
This should be changed somehow. One "solution" that comes into my mind
would be to give each path name its own inode on the client (for nfs
only, of course) no matter what i_nlink says.
MMh. This cannot work with async writes; it would add hell of a lot of
inconsistance w.r.t. async writes. Async reads would be okay.
Actually, to make the stuff work I suspect that one would have to give
access not only to the inode for inode operations, but provide also
the pathname, i.e. make everyting dentry based. The inode pointer
merely would be the pointer to the real object.
But this cannot work either. It would break abstraction boundaries
like hell.
Cheers and good night
Claus