From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andreas Dilger <adilger@dilger.ca>, NeilBrown <neilb@suse.de>,
Miklos Szeredi <miklos@szeredi.hu>,
Bruce Fields <bfields@fieldses.org>,
linux-man@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
Ganesha NFS List <nfs-ganesha-devel@lists.sourceforge.net>
Subject: Re: name_to_handle_at() and persistent filesystem IDs
Date: Sun, 16 Mar 2014 20:38:32 +0530 [thread overview]
Message-ID: <8761netc3z.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAHO5Pa0Y8r1DxHTc0YN-4geoLJ3JYwHT99EcuaGL6k++ek+aEQ@mail.gmail.com>
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:)
-aneesh
next prev parent reply other threads:[~2014-03-16 15:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-16 7:43 name_to_handle_at() and persistent filesystem IDs Michael Kerrisk
2014-03-16 15:08 ` Aneesh Kumar K.V [this message]
2014-03-17 16:16 ` Michael Kerrisk (man-pages)
2014-03-17 17:01 ` [Nfs-ganesha-devel] " Frank Filz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761netc3z.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@dilger.ca \
--cc=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mtk.manpages@gmail.com \
--cc=neilb@suse.de \
--cc=nfs-ganesha-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox