On Wed, May 03, 2000 at 11:27:34AM +0200, Andi Kleen wrote:
> On Tue, May 02, 2000 at 11:20:10PM +0200, Steve Dodd wrote:
> > First off, could we call them "inode labels" or something less confusing?
> > "file" outside of NFS has a different meaning (semantic namespace collision
> > <g>) Also, I don't see how a "fh_to_dentry" (or ilbl_to_dentry) is going to
> > work - (think hardlinks, etc.). You do need an iget_by_label or something
>
> NFS file handles are always a kind of hard link, in traditional Unix
> they refer directly to inodes. Linux knfsd uses dentries only because the
> VFS semantics require it, not because of any NFS requirements.
What I meant was, you can't have a "ilabel_to_dentry" (or fh_to_dentry for
that matter <g>) function because there may well be more than one dentry
pointing to the inode.
As for NFS's use of dentries, I'm still not sure I understand all the
details. Without having reading the specs, I would expect it to be operating
mostly on inodes, but I'm sure there are good reasons why it doesn't.
[..]
> iget_by_label() is already implemented in 2.3 -- see iget4(). Unfortunately
> it is a bit inefficient to search inodes this way [because you cannot index
> on the additional information], but not too bad.
iget4 isn't quite the same -- you need to supply a "find actor" to compare
the other parts of the inode identifier, which are fs-specific. knfsd wouldn't
be able to supply a find actor for the underlying filesystem it was serving.
> > Also, what are the size constraints imposed by NFS? What about other network
> > filesystems?
>
> NFSv2 has 2GB limits for files.
Sorry, I was thinking more of limits imposed on the size of the "file handle" /
inode identifier..
