Re: [PATCH -V7 3/9] vfs: Add name to file handle conversion support

[Aneesh Kumar K. V]

On Sat, 15 May 2010 07:00:23 +0100, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Sat, May 15, 2010 at 11:01:13AM +0530, Aneesh Kumar K. V wrote:
> 
> > We need to have a file system identifier to identify a file system with
> > respect to which file_id need to be decoded.
> 
> Obviously.
> 
> > We can either do it in
> > userspace via statfs or any other encoding or let the kernel fill the
> > field for userspace. Now having kernel providing both file_id and file
> > system id implies we can get an 'unique' handle with one syscall. (Not
> > unique if we have multiple file system with same UUID. Userspace
> > file server can find out whether all the mount point it is exporting
> > have a unique UUID during startup.) 
> 
> Or it can decide which UUID to use by parsing its analog of /etc/exports, or
> any number of other schemes.  Sure.
> 
> > Now if we have UUID as a part of file handle, adding the check make
> > sure that we are passing the right file handle with the correct mountdirfd.
> > If they don't match return -ESTALE. 
> 
> Pardon?  Your variant needs to choose mountdirfd somehow and it has to be
> done by UUID found in fhandle it has received.  Whatever userland code will
> be doing that, you
> 	a) need to open() these suckers at some point
> 	b) do _NOT_ want to reopen them on each incoming fhandle, for obvious
> efficiency reasons
> 	c) will have very few opens compared to the amount of fhandles you
> are going to handle (number of filesystems vs. number of requested accesses
> to them)
> 	d) can be sure that identity of fs hosting an opened directory will
> _not_ change while it's open, so the checks concerning the validity of
> UUID -> mountdirfd mapping you need to do should be done only once per
> opening mountdirfd
> 
> So why the devil would you repeat them on each open-by-fhandle in a variant
> that gets mountdirfd from caller?
> 
> > Adding UUID as a part of file handle also help us to get a 16 byte UUID
> > of the file system in userspace in a simple syscall interface, rather
> > than using file system specific libraries like libext2fs.
> 
> Your choice of fsid encoding is orthogonal to my question; again, the question
> is "why would you want to have open-by-fhandle do anything with fsid, if it
> gets filesystem identified by opened file descriptor passed by userland anyway?"
> 
> I don't think that UUID is always a good choice, BTW, but that's a separate
> issue.  For one thing, not every fs _has_ UUID, so while that might be a
> reasonable default, it doesn't make sense to hardwire it into the design.
> For another, you might want a different policy (e.g. you might want to
> allow explicitly configured "this fsid value corresponds to whatever's mounted
> on that path" for some userland server), so again it doesn't make any sense
> to hardwire that one.
> 
> But that's a completely independent issue; whether you use hardwire UUID into
> the thing or not, rechecking that yes, mountdirfd is on the same fs as it
> used to back when we'd opened it, is pointless.  It *will* be on the same fs,
> so checking that we'd got the right filesystem should be done once per
> opening mountdirfd, not once per opening file by fhandle.

Ok that made it clear. Thanks for the explanation. BTW we still are ok
with UUID/16byte array to be part of file handle returned by the kernel
right? ie file_handle of type.

struct file_handle {
	int handle_size;
	int handle_type;
	/* File system identifier */
	struct uuid fsid;
	/* file identifier */
	unsigned char f_handle[0];
};

If the file system provide an unique identifier it can return that via
super_block->s_ops->get_fsid. If not just don't implement the call back. We
don't validate the UUID in the handle on open_by_handle because the
user space server could use a file system identifier different from
the file system UUID.

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/