>
> 2. The NFS client uses iget to keep track of outstanding inodes which
> keys its hash table on superblock and fileid as returned from the
> NFS server. This fileid really should be opaque to the kernel,
> and the table should be indexed by NFS filehandles which are
> guaranteed to be unique. Otherwise, a server can't export a
> volume on a subdirectory of itself without confusing the Linux
> kernel completely. User-space programs will then make use of the
> fileid (inode number) to avoid disasters like copying a file onto
> itself.
>
> My quick temporary solution here was to add a new version of iget
> that indexed the hash table based on a combination of the
> superblock, fileid, and filehandle. In this way, two files with
> the same fileid and different filehandles would hash to different
> locations. Of course, we could still have hash collisions, so a
> better solution is to have iget take as arguments an arbitrary
> length FS-defined key (instead of inode) and a hash function for
> iget to call on the key.
>
This will not work. You can't use the filehandle, since it is not
unique to the inode (consider hard links).
The reason why I didn't go for a hashing scheme (but, for the moment,
allow aliasing of inode number) is because you cannot map a 64-bit
value uniquely onto 32-bits. Hashing will force you to alias inode
numbers at least as often as a direct map (it will probably occur more
often if the server is using 32-bit fileid values).
My current NFSv3 patches therefore rely on the 128-bit fsid+fileid to
identify the file on the NFS server side, and the pointer to the inode
structure to label it on the Linux side.
The inode number cannot be guaranteed to identify files uniquely on
NFSv3 until we make it a 64-bit value. I haven't done that since it
would entail a lot more work in maintaining patches, and would break
libc et al...
Cheers,
Trond
-
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/