Re: [PATCH -V3] Generic name to handle and open by handle syscalls

[Neil Brown <neilb@suse.de>]

On Mon, 26 Apr 2010 05:56:58 -0400
Christoph Hellwig <hch@infradead.org> 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