On Mon, 26 Apr 2010 05:56:58 -0400
Christoph Hellwig <hch@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
