On Wed, May 03, 2000 at 11:57:52PM +0200, Steve Dodd wrote:
> 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.
It does not matter, as long as you get some dentry pointing to it.
The new nfs file handle code even uses anonymous dentries in some
cases (dentries not connected to the dentry tree).
The nfsfh conceptually just acts like another hard link.
The standard 2.2 code is really broken because it cannot handle renaming
of directories (because the file handles are path dependent). 2.3/
2.2+sourceforge code tries to fix this mostly with some evil tricks.
> 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.
NFS wants to operate on inodes, but Linux 2.2+ VFS does not allow it
(that is why the nfsfh.c code is so complex -- in early 2.1 knfsd
before the dcache architecture was introduced nfsfh.c was *much* simpler)
>
> [..]
> > 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.
``with some trivial extensions''
The 2.3 nfsfh code supports arbitary file handle types, indexed with
an identifier. You would associate the find_actor with an specific
identifier. Some fs specific code is needed anyways to write the
private parts into the fh (e.g. in the reiser case for writing
the true packing locality)
>
> > > 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..
NFSv2 has 32bytes file handles. NFSv3 has longer ones.
For all current versions of reiserfs the necessary information can
be squeezed into 32bytes with some tricks.
-Andi
--
This is like TV. I don't like TV.
