Message-ID: <20100515060023.GC31073@ZenIV.linux.org.uk>
Date:	Sat, 15 May 2010 07:00:23 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	Andreas Dilger <andreas.dilger@...cle.com>,
	Neil Brown <neilb@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	Jonathan Corbet <corbet@....net>,
	Serge Hallyn <serue@...ibm.com>, linux-fsdevel@...r.kernel.org,
	Steven French <sfrench@...ibm.com>,
	Philippe Deniel <philippe.deniel@....FR>,
	"linux-kernel@...r.kernel.org Mailinglist" 
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -V7 3/9] vfs: Add name to file handle conversion support

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists