Re: name_to_handle_at() and persistent filesystem IDs

[Aneesh Kumar K.V]

Michael Kerrisk <mtk.manpages@xxxxxxxxx> writes:

> Hello Aneesh,
>
> I'm currently working on a man page for name_to_handle_at() and
> open_by_handle_at(), and I have a question relating to a point that
> probably needs to be covered in the man page.
>
> Back in July 2010, in this thread:
> http://thread.gmane.org/gmane.linux.file-systems/41782/focus=43131
> you said:
>
> [[
> 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.
> ]]
>
> In the man page, I'd like to briefly describe how one derives such a
> persistent ID from mountinfo. AFAICS, the optional UUID tag in
> /proc/self/mountinfo has not come to pass. So, what then is the
> recommended practice for deriving the persistent ID?
>

Anything that work for the application. mount_id will indicate which
mount it is ie. from /proc/self/mountinfo

30 20 8:1 / /boot rw,relatime - ext4 /dev/sda1 rw,data=ordered

The value 30 helps us to figure out that we are looking at device
/dev/sda1. With that we can derive the uuid using libblkid.  I am not sure we
concluded anything really about how to identify an nfs mount. May be we
can do that based on server and mount point details ?.But from the
syscall point, what we return is mount_id, which gives a hint regarding
which mount point we are talking about in /proc/self/mountinfo. From
that information applications can use any method that work for them
to derivce an unique identifier.

I know that NFS ganesha use these syscall. May we can check with them
what worked for them ? (Added to CC:)
 
-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/