From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: [PATCH -V3] Generic name to handle and open by handle syscalls Date: Mon, 26 Apr 2010 20:16:33 +1000 Message-ID: <20100426201633.0989254f@notabene.brown> References: <1271960133-16414-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <20100424110812.40989988@notabene.brown> <20100426095658.GD23020@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Andreas Dilger , Theodore Tso , "Aneesh Kumar K.V" , viro@zeniv.linux.org.uk, corbet@lwn.net, linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com To: Christoph Hellwig Return-path: Received: from cantor2.suse.de ([195.135.220.15]:36958 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396Ab0DZKQt (ORCPT ); Mon, 26 Apr 2010 06:16:49 -0400 In-Reply-To: <20100426095658.GD23020@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 26 Apr 2010 05:56:58 -0400 Christoph Hellwig wrote: > On Sat, Apr 24, 2010 at 11:08:12AM +1000, Neil Brown wrote: > > Maybe map the filesystem part of the handle from UUID (or whatever) to devno > > in userspace, then pass the devno+file-part-of-handle to the kernel to > > perform, the final mapping. > > The device number is not a useful kernel interface at all. Getting a > uuid really is easy in kernelspace as it's available in the superblock > for every reasonable fs. What's more difficult is finding the right > vfsmount instance of a superblock to use - not just due to read only > but also things like no* per-vfsmount flags. > > If you look at libhandle in xfsprogs which wraps the existing xfs handle > ioctls for use in application you'll see such a hash table to map to > open file descriptors per filesystems due to the limits of the ioctl > interface. Doing the uuid lookup in kernelspace sounds much saner as > we have a list of mounts there anyway. 'device number' is useful in that it is guaranteed to be unique, and fairly trivial to simply generate a unique one in the kernel with no real cost for any lack of stability. Don't think of it as a device number - think of it as a system-wide filesystem-descriptor. You mount a filesystem and then use lstat to find out what fsd was allocated and use that. Sometimes it will be based on the major/minor of a related device, other times it will not. It is already the key that is used for accessing the per-filesystem bdi via /sys/class/bdi/XX:XX/... for setting e.g. read_ahead_kb and {min,max}_ratio. uuids - as Ted as shown - are not necessarily unique (despite the name), so using them to perform a lookup will either be imperfect (not good for a kernel interface) or will impose extra uniqueness which would break current configurations. Surely the imperfection of the mapping is best handled in user-space, with policy such as "prefer writeable snapshot" etc. NeilBrown