On Mon, 17 Apr 2006, Neil Brown wrote: > 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? Something like getattrlist() system call on OSX would do very nicely. It even allows for filesystems to communicate which attributes are supported and which are not. (And there is an equivalent setattrlist(), too.) http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getattrlist.2.html On the kernel VFS/FS interface side this works by the VFS sending a bitmask to the FS, with each bit being one of the attributes requested and for each set bit, the FS returns the appropriate information in the "getattr structure" and sets a flag in a second bitmask to say "I have returned this attribute". The VFS then converts the returned attribute values as signified by set bits in the second bitmask from the structure returned by the FS into the user supplied buffer in a packed form (see the above man page for details on the packed form). This works very well and is very extensible. Linux already has a per FS getattr() inode operation which could easily be extended to be more powerful and a system call could be added to return information obtained from it... Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ - 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
