linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Kerrisk <mtk.manpages@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.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>
Subject: name_to_handle_at() and persistent filesystem IDs
Date: Sun, 16 Mar 2014 08:43:58 +0100	[thread overview]
Message-ID: <CAHO5Pa0Y8r1DxHTc0YN-4geoLJ3JYwHT99EcuaGL6k++ek+aEQ@mail.gmail.com> (raw)

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/

             reply	other threads:[~2014-03-16  7:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-16  7:43 Michael Kerrisk [this message]
     [not found] ` <CAHO5Pa0Y8r1DxHTc0YN-4geoLJ3JYwHT99EcuaGL6k++ek+aEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-16 15:08   ` name_to_handle_at() and persistent filesystem IDs Aneesh Kumar K.V
2014-03-17 16:16     ` Michael Kerrisk (man-pages)
     [not found]     ` <8761netc3z.fsf-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
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=CAHO5Pa0Y8r1DxHTc0YN-4geoLJ3JYwHT99EcuaGL6k++ek+aEQ@mail.gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=adilger@dilger.ca \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --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=neilb@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).