The way I'm reading it is that if the file handles are different, it
doesn't matter at all what the fileid is, you're not allowed to conclude
that the files are the same.
> > Currently, the kernel makes the assumption they are the same
> > implicitly, by only using fileid to lookup inodes.
>
> This is not so bad because the RFC also says:
>
> "fsid" is the file system identifier for the filesystem containing
> the file; "fileid" is a number that uniquely identifies the file
> within its filesystem
>
> Note the "uniquely". But why do we not make use of the fsid value?
We actually do; by "only" I meant to say "not including the
filehandle." But I think your point about "uniquely" seems to support
what I'm saying. If two files have the same fileid (say they're
hardlinked) then they're the same file within the server's filesystem.
In order for the NFS client to guarantee they're the same file locally,
the server needs to give both instances of the file the same handle.
If it doesn't, the server has no clue what the client will do because
of the "no conclusions can be drawn." I agree that the language is a
bit confusing.
My problem is actually when the server does give the same file (i.e.,
same fileid) two different handles because it wants the client to
think they are different files. For example, the server exports the
same volume twice.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/