On Fri, 9 Jul 2010 12:42:42 -0600, Andreas Dilger <adilger@xxxxxxxxx> wrote: > On 2010-07-08, at 06:21, Neil Brown wrote: > > On Thu, 08 Jul 2010 16:10:09 +0530 > > "Aneesh Kumar K. V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > >> How about adding mnt_id to the handle ? Documentation file says it is unique > >> > >> (1) mount ID: unique identifier of the mount (may be reused after umount) > > But this value is not persistent across a reboot, or even an > umount/mount so it is not useful as an identifier. mount id should not be looked at as a persistent identifier. It should be used to derive a persistent identifier from /proc/self/mountinfo. The persistent identifier could be the combination of device properties, file system properties or the uuid which is going to be an optional tag in /proc/self/mountinfo. This also implies we need to hold a reference in the mount to make sure we can safely lookup uuid using mount id. > > I suppose one way to resolve this issue is to just allow the > underlying filesystem to supply a completely opaque filehandle to > userspace. For local filesystems that don't care about persistence or > uniqueness between nodes they can use something like mount_id, and for > distributed/clustered filesystems they can include a globally-unique > identifier. We could use mountid to get the persistent id from mountinfo right ? So file handle request would include fd = open(name); file_handle = fd_to_handle(fd); fs_uuid = get_uuid(file_handle.mnt_id); close(fd); So for your usecase the handle send to other nodes include will include cluster_fs_uuid and file_identifier. -aneesh -- 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
