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

[Frank Filz]

> 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:)

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-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/