Re: [PATCH] address_space_operations unification

From: Neil Brown (
Date: Tue May 09 2000 - 20:55:25 EST

On Tuesday May 9, wrote:
> On Tue, May 09, 2000 at 10:43:57AM +0200, Trond Myklebust wrote:
> > >>>>> " " == Roman V Shaposhnick <> writes:
> >
> > > Hm, I don't know about knfsd people but I am thinking about
> > > something like
> > > fh_to_dentry and dentry_to_fh pair. The main idea ( suggested
> > > by Al ) is to allow dentry tree to grow in two different
> > > directions: from root to leaves and from leaves to root. The
> > > main trick will be to select right splicer and to allow quick
> > > grow for upside direction. It seems, that this will satisfy NFS
> > > as is, and will provide a way for unique "external"
> > > representation of the dentry tree.
> >
> > Don't forget that for the case of NFS at least, you have to be able to
> > locate a file anywhere in the dentry tree from scratch after a server
> > reboot (All hail the god of stateless models). An fh_to_dentry() model
> > would need to do this too in an as efficient manner as possible.
> Yes, of course, the whole idea is to let filesystem to decide whether it
> could provide something as a rock solid invariant ( that will even survive
> after reboot ) or not. And if it can, let it do this via a generic interface.
> Thus the filesystem will be consider exportable if it has non trivial
> fh_to_dentry and dentry_to_fh -- no more wild guessing.
> > I believe Neil has been working on a proposal for this within the
> > knfsd project, so I've Cced him in case he was unaware of this thread.
> It would be great to hear from him what is the current state of this
> proposal.
> Thanks,
> Roman.

Current state: Limbo.

I got as far as generalising the structure of the filehandle so that
it would be easy to pass the per-filesystem specific part to/from the
particular filesystem. The next step would be defining an interface
in the vfs layer, getting knfsd to use that interface if present, and
then supporting that interface in any filesystems that we want to

However, Al Viro was talking about doing this sort of thing, so I
thought I would leave it to him and not step on his territory -- from
what little bits I have gleaned of what he is planning, it sounds

Were I to try to push it forward a bit, I would first want to agree on
an interface. Given that it would be any easy job to get knfsd to use
the interface if it were available. I would then be very happy to
leave individual filesystem people to implement it in their own

The interface that I would suggest would be to add to

 struct dentry *(*resolv_fh)(struct super_block *sb,
                          char *fh,
                          int fh_len,
                          char flavour,
                          struct dentry *base);
 int (*build_fh)(struct dentry *target,
                 char *fh,
                 int fh_len,
                 char *flavour,
                 int flags);


 "fh" is a pointer to a 4-byte aligned point in the file handle where
     the filesystem specific part of the filehandle is.
 "fh_len" is the amount of space left in the filehandle. It may indicate
     more space than build_fh said was used.
 "flavour' is one byte which is stored elsewhere in the filehandle.
     0 may not be used
     1 must be interpreted as "4 byte inode number, 4 byte generation
     2 must be interpreted as "4 byte inode number, 4 byte generation
       number, 4 byte inode number of parent directory"

     alternatively, 1 and 2 can simply not be used.

 "base", if non-NULL, means "make sure that the returned dentry is a
     descendant of "base".

 "flags" can be "NFSD_FH_LOCATABLE" meaning that "resolv_fh" will
     probably be called with a non-NULL "base", so you might want to
     include extra information in the file handle so that you can meet the
     requirements of base being non-NULL.

  resolv_fh returns a dentry, or an error status via ERR_PTR
  build_fh returns the number of byte os the filehandle that was
  encoded, or a -ve errno code.

  I could probably live with the "flavour" field if it was thought to
  be ugly, but I think the rest if necessary.

  If there is agreement on this interface, then I would be happy to
  update knfsd to make use of it where available.

 It might also be necessary to have some sort of interface where-by
 knfsd can get answers to such questions as:

   - can you support NFSD_FH_LOCATABLE
   - is file name comparison case insensitive (will be needed for NFSv4)
   - what is the maximum file size


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST