On Wednesday April 12, green@xxxxxxxxxxxxxx wrote:
>
> I wonder if e.g. another export op could be introduced to ask filesystem
> for its unique id (if supported) and use that instead of sb->s_dev in
> fsid calculations. Does this look sane?
> I hope I am not missing anything?
> Or are there better ideas?
>
Yes. fsid= is a problem. Getting information from the filesystem
would be nice. But there are issues of practicality.
The NFS filehandle is of limited size.
For NFSv2 we have 32 bytes and we cannot really afford more than 4 to
identify the filesystem.
4 bytes isn't really enough for a globally unique ID. Many
filesystems have UUIDs but I would expect them to be more like 16
bytes.
Such a number could be hashed down to 4bytes, but you would greatly
increase the risk of collision.
Ofcourse, NFSv2 is pretty old now, and it is probably reasonable to
have features that are only available to v3 or later.
v3 has space in the filehandle for up to 64 bytes. It would probably
be OK to allow upto 16 - or maybe 20 - bytes to identify the
filesystem.
There is still the issue of a filesystem having multiple export
points, though that isn't really a big issue as it is rarely needed so
we can impose extra constraints (you must give fsid=) in that case.
So there remains the question of whether this should be handled in the
kernel or in user-space. There already exists libblkid which can
produce UUIDs for various filesystems (I believe). But that reads the
block device, and the whole point of this is to work with filesystems
that don't have a simple block device.
I'd rather not make the 'get uuid' be an export op as it could well be
useful to other clients than just nfsd.
Unfortunately there is no unanimity of how to present filesystem
metadata to userspace.
- ioctls are frowned upon
- extended attribute have been suggested, they are about files,
not filesystems
- filesystems don't have a place in /sys
- /proc is frowned upon
Here is an idea: How about we make a magic filesystem mounted on e.g.
/metafs, which examines the current directory of the accessing process
in order to report metadata.
So
cd /my/mount/point
cat /metafa/uuid
will show the uuid of the fs at /my/mount/point...
OK, so that's really weird. But I think there is a real need to be
able to expose filesystem metadata in a uniform way and I would like
the uuid to be made available through that.
With that in place, I would be happy to look at including a uuid in
the filehandle for v3.
Any ideas?
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
