On Thursday June 15, vugluskr@unicorn.math.spbu.ru wrote:
> Folks, it seems that now I have something that can be considered as a very
> first attempt to implement proper file handles on a per-fs basis.
>
> The main idea behind all this stuff is that it should be up to each filesystem to
> decide whether it wants to be exportable or not. And if yes -- provide
> strong invariants for external representation of its objects to the knfsd
> module via two (hope!) well defined procedures:
> fhandle_to_dentry()
> dentry_to_fhandle()
>
> As an example I took ext2 and hacked around namei.c. Take a look at it and
> *please* express what do you think about the approach in general ( not
> the coding style ;).
>
> Now for the implementation details:
>
> 0. include/linux/fs.h:
> just a few declarations.
> 1. knfsd part:
> 1.1. export.c: as I've already said an fs is said to be exportable iff
> it provides fhandle_to_dentry & dentry_to_fhandle.
> 1.2. nfsfh.c: a lot of changes and not only in interface but also
> in how subtrees are being checked. Trond, please take a look at
> this beast ( it is from your forest ;). I'm asking because this
> part, I mean knfsd, is pretty independent and should be purified
> before we will start hacking filesystems.
Probably more my neck of the woods than Trond's, though I'm sure he
has valuable opinions
You seem to have completely missed the point of the new structure of
the file handle.
The idea was that the tail end of the filehandle was "owned" by the
file system. You pass a "char *" (or void*) to the filesystem, and it
extracts what it wants, or fills in what it has as appropriate.
So extracting two longs, giving them names, and passing them to the
filesystem just isn't the right idea. The only reason that the
extracting-two-longs code is in there is for back-compatibility.
The filesystem might want to store 64 bit numbers, or several
different numbers which are each possible keys (in the case of a
filesystem not having a guarnteed key). The knfsd layer really
shouldn't care.
Also, ripping out the "security" stuff is a bit unfriendly. I think
it does have a place, even if you don't think it gives much extra
security, and quoting RFC[1094|1813] isn't really the point. These,
particularly 1094, are very bare-bones protocol descriptions. There
is a lot that they don't say about implementation that can still be
very important.
You said in a separate Email that:
But my strong opinion here is that this kind of trickery should stay on
a protocol level and it should not be integrated into VFS filehandles.
My perspective is:
The need is "given a file(handle), find the parent". The NFSD layer
can only do this by grabbing a filehandle for the directory as
well. The filesystem could concievably find it much easier. It
might have a record of the directory in the file object (I think the
Domain/OS filesystem did this). So it is a task best left to the
filesystem. Quite possibly support routines could live somewhere
so that each filesystem didn't have to duplicate code, but each file
system should have control of how it identifies the parent.
Also, from a project management perspective, I think it would be best
to leave knfsd only requires read_inode OR the two new procedures, and
leave the old code there to cope with filesystems that haven't defined
the new procedures yet. That way you can have a graceful transition.
You asked by opinion on this a while ago and you seem to have ignored
it? Maybe you just didn't recieve it, so here it is again.
----------------------------------------------------------------
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
----------------------------------------------------
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 : Fri Jun 23 2000 - 21:00:11 EST