On Tue, 2008-09-02 at 11:09 -0600, Andreas Dilger wrote: > The fsid is supposed to be a persistent, unique identifier for the > filesystem, used by NFS in file handles. Using st_dev is unsafe, > because that may change from one server boot to the next, because > of device probing order, driver changes, etc. Also, not all > filesystems > HAVE a valid st_dev in the first place, which is the whole reason > for this thread. Yes, putting st_dev in f_fsid probably isn't a good thing to do. > I think a ->get_fsid() export method would be preferable. I implemented that, but it doesn't really work. The fsid->export mapping happens in userspace, so mountd needs access to the fsid. So the mount would work fine and return a FH with the appropriate fsid, and then mountd would have no knowledge of how to handle that FH, and mount(8) on the client would eventually time out and fail. It worked if I prepopulated the nfsd.fh cache in expkey_parse() so we didn't end up asking userspace to resolve that FH for us -- but that was just a quick hack. It wouldn't have worked after a server reboot, for example -- we'd have asked userspace again. We'd need to export that fsid to userspace somehow. I did briefly think about adding something like ',uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' to each line in /proc/mounts, as if it was a file system option -- but I don't like that much. When looking for other options, I realised that we already have the f_fsid field in struct statfs, and we might as well just use that. That does seem to be what it was _designed_ for, after all. -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation -- 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
