On Tue, May 02, 2000 at 11:20:10PM +0200, Steve Dodd wrote:
> On Tue, May 02, 2000 at 01:50:16PM -0700, Chris Mason wrote:
> >
> > ReiserFS has unique inode numbers, but they aren't enough to actually find
> > the inode on disk. That requires the inode number, and another 32 bits of
> > information we call the packing locality. The packing locality starts as
> > the parent directory inode number, but does not change across renames.
> >
> > So, we need to add a fh_to_dentry lookup operation for knfsd to use, and
> > perhaps a dentry_to_fh operation as well (but _fh_update in pre6 looks ok
> > for us).
>
> 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.
> similar though. Details that need to be worked out would be max label size
> and how they're passed around (void * ptr and a length?)
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.
>
> Also, what are the size constraints imposed by NFS? What about other network
> filesystems?
NFSv2 has 2GB limits for files.
-Andi
