On Tuesday May 9, roman@yellow.pdmi.ras.ru wrote:
> On Tue, May 09, 2000 at 10:43:57AM +0200, Trond Myklebust wrote:
> > >>>>> " " == Roman V Shaposhnick <roman@yellow.pdmi.ras.ru> 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
export.
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
good.
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
filesystems.
The interface that I would suggest would be to add to
super_operations:
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);
#define NFSD_FH_LOCATABLE 1
"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
number"
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
NeilBrown
-
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/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST