From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
david@fromorbit.com, aneesh.kumar@linux.vnet.ibm.com,
hch@infradead.org, viro@zeniv.linux.org.uk, adilger@sun.com,
corbet@lwn.net, serue@us.ibm.com, hooanon05@yahoo.co.jp,
linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com,
philippe.deniel@CEA.FR, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V14 0/11] Generic name to handle and open by handle syscalls
Date: Wed, 7 Jul 2010 18:25:51 -0400 [thread overview]
Message-ID: <20100707222551.GA9878@fieldses.org> (raw)
In-Reply-To: <20100708082143.3701bfc7@notabene.brown>
On Thu, Jul 08, 2010 at 08:21:43AM +1000, Neil Brown wrote:
> On Wed, 7 Jul 2010 10:45:11 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
> > On Wed, Jul 07, 2010 at 03:35:50PM +0200, Miklos Szeredi wrote:
> > > It's unique at a single point in time. But if you have a reference
> > > (e.g. open file descriptor) on the mount then that's not a problem.
> > >
> > > fd = open(path, ...);
> > > fstat(fd, &st);
> > > search st.st_dev in mountinfo
> > > close(fd)
> > >
> > > is effectively the same as an getuuid(path) syscall (lazy unmounted
> > > filesystems will not be found in mountinfo, but the reference is still
> > > there so st_dev will not be reused for other filesystems).
> >
> > OK, cool.
> >
> > That still leaves the problem that there isn't always an underlying
> > block device, and/or when there is it doesn't always uniquely specify
> > the filesystem.
>
> It doesn't matter if there is an underlying block device, or if it is shared
> among subvolmes.
> st_dev is *the* primary key for filesystems. Every "struct super_block" has a
> unquie s_dev and that is returned in st_dev.
>
> For "traditional" filesystem, this is the major/minor number of the block
> device.
> For NFS and btrfs and other filesystems which don't have exclusive use of a
> block device, 'set_anon_super' is used to get a unique s_dev based on a major
> number of '0'.
Whoops, OK, thanks for the explanation.
--b.
> So you can *always* use st_dev as an identifier for the filesystem which is
> stable and unique as long as you hold an active reference to the filesystem
> (open file descriptor, cwd in fs, etc).
>
> If you poll(2) /proc/mounts to get notifications of changes to the mount
> table, then it should be quite easy to cache st-dev -> uuid mappings in a
> race-free way.
>
> There might be value in getting name_to_handle to return the st_dev of the
> target file to ensure that you haven't unexepected crossed into a different
> filesystem. I would prefer that to returning a uuid: st_dev is guaranteed
> to be unique, a uuid is only supposed to be unique (i.e. that is not
> enforced).
>
> NeilBrown
next prev parent reply other threads:[~2010-07-07 22:26 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-15 17:12 [PATCH -V14 0/11] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 01/11] exportfs: Return the minimum required handle size Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 02/11] vfs: Add name to file handle conversion support Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 03/11] vfs: Add open by file handle support Aneesh Kumar K.V
2010-07-07 15:17 ` Nick Piggin
2010-07-07 16:16 ` Aneesh Kumar K. V
2010-06-15 17:12 ` [PATCH -V14 04/11] vfs: Allow handle based open on symlinks Aneesh Kumar K.V
2010-07-07 15:23 ` Nick Piggin
2010-07-07 16:24 ` Aneesh Kumar K. V
2010-07-07 16:57 ` Nick Piggin
2010-07-07 17:53 ` Aneesh Kumar K. V
2010-07-07 18:20 ` Nick Piggin
2010-07-07 16:48 ` Nick Piggin
2010-07-08 10:42 ` Aneesh Kumar K. V
2010-06-15 17:12 ` [PATCH -V14 05/11] vfs: Support null pathname in readlink Aneesh Kumar K.V
2010-07-07 15:27 ` Nick Piggin
2010-07-07 16:32 ` Aneesh Kumar K. V
2010-07-07 17:03 ` Nick Piggin
2010-06-15 17:12 ` [PATCH -V14 06/11] ext4: Copy fs UUID to superblock Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 07/11] x86: Add new syscalls for x86_32 Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 08/11] x86: Add new syscalls for x86_64 Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 09/11] ext3: Copy fs UUID to superblock Aneesh Kumar K.V
2010-06-15 17:13 ` [PATCH -V14 10/11] vfs: Support null pathname in faccessat Aneesh Kumar K.V
2010-06-15 17:13 ` [PATCH -V14 11/11] vfs: Support null pathname in linkat Aneesh Kumar K.V
2010-07-01 16:28 ` [PATCH -V14 0/11] Generic name to handle and open by handle syscalls Aneesh Kumar K. V
2010-07-01 20:41 ` Neil Brown
2010-07-01 21:15 ` Aneesh Kumar K. V
2010-07-06 16:10 ` J. Bruce Fields
2010-07-06 17:09 ` Aneesh Kumar K. V
2010-07-06 23:23 ` Dave Chinner
2010-07-06 23:36 ` Neil Brown
2010-07-07 2:11 ` Dave Chinner
2010-07-07 2:57 ` Neil Brown
2010-07-07 12:44 ` Miklos Szeredi
2010-07-07 12:57 ` J. Bruce Fields
2010-07-07 13:10 ` Miklos Szeredi
2010-07-07 13:17 ` J. Bruce Fields
2010-07-07 13:35 ` Miklos Szeredi
2010-07-07 14:45 ` J. Bruce Fields
2010-07-07 16:33 ` Aneesh Kumar K. V
2010-07-07 16:39 ` J. Bruce Fields
2010-07-07 22:21 ` Neil Brown
2010-07-07 22:25 ` J. Bruce Fields [this message]
2010-07-08 0:03 ` Andreas Dilger
2010-07-08 5:03 ` Neil Brown
2010-07-08 10:40 ` Aneesh Kumar K. V
2010-07-08 11:52 ` Miklos Szeredi
2010-07-08 12:21 ` Neil Brown
2010-07-09 18:42 ` Andreas Dilger
2010-07-10 4:58 ` Aneesh Kumar K. V
2010-07-07 7:40 ` Andreas Dilger
2010-07-07 15:05 ` J. Bruce Fields
2010-07-07 17:02 ` Andreas Dilger
2010-07-07 17:37 ` J. Bruce Fields
2010-07-07 18:05 ` Nick Piggin
2010-07-07 23:49 ` Andreas Dilger
2010-07-07 18:18 ` Aneesh Kumar K. V
2010-07-07 20:39 ` Alan Cox
2010-07-07 23:54 ` Andreas Dilger
2010-07-02 4:02 ` Andreas Dilger
2010-07-02 7:05 ` hch
2010-07-02 16:12 ` Andreas Dilger
2010-07-02 22:09 ` Neil Brown
2010-07-02 22:47 ` Andreas Dilger
2010-07-03 16:04 ` Aneesh Kumar K. V
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=20100707222551.GA9878@fieldses.org \
--to=bfields@fieldses.org \
--cc=adilger@sun.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=corbet@lwn.net \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=hooanon05@yahoo.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=philippe.deniel@CEA.FR \
--cc=serue@us.ibm.com \
--cc=sfrench@us.ibm.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.