name_to_handle_at() and persistent filesystem IDs

name_to_handle_at() and persistent filesystem IDs

[Michael Kerrisk]

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?

Cheers,

Michael

-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

Re: name_to_handle_at() and persistent filesystem IDs

[Aneesh Kumar K.V]

Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: name_to_handle_at() and persistent filesystem IDs

[Michael Kerrisk (man-pages)]

Hello Aneesh,

On Sun, Mar 16, 2014 at 4:08 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Michael Kerrisk <mtk.manpages@gmail.com> 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:)

Thanks, that helped, as as I hope is evident from the page I just sent.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

RE: [Nfs-ganesha-devel] name_to_handle_at() and persistent filesystem IDs

[Frank Filz]

> Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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:)

Ganesha ignores the mount id. It's not really clear how it would be used
(would it help detect file system junctions?) since it isn't required on
open_by_handle_at, it's just a return param from name_to_handle_at.

Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html