All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Neil Brown <neilb@suse.de>
Cc: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	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 12:11:50 +1000	[thread overview]
Message-ID: <20100707021150.GF25018@dastard> (raw)
In-Reply-To: <20100707093629.10c2feab@notabene.brown>

On Wed, Jul 07, 2010 at 09:36:29AM +1000, Neil Brown wrote:
> On Wed, 7 Jul 2010 09:23:51 +1000
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > > I can add a new syscall that returns 
> > > 
> > > struct fs_uuid {
> > >        u8 fs_uuid[16];  
> > > };
> > > 
> > > long sys_get_fs_uuid(int dfd, char *name, struct fs_uuid *fsid, int flag);  
> > 
> > libblkid already provides the UUID to userspace applications, doesn't it?
> 
> Yes and no.
> 
> libblkid provides the uuid of the thing that uses a block device.  That
> doesn't directly map to "UUID of a filesystem".

True.

> There are two types of filesystem that I can think of for which libblkid
> cannot give a uuid.
>   - network filesystems (or virtual filesystems, or fuse )

How would you guarantee persistent uniqueness for such filesystems?

>   - filesystems which share a block device, such as btrfs.
>     btrfs can have 'subvols' - multiple "filesystems" within
>     the one (set of) block device(s).  libblkid cannot be asked about these
>     different subvols.
> 
> libblkid is useful, but not a real solution.

So libblkid doesn't cover everything, but I think my question is
still valid - if we want per-filesystem UUIDs, why a syscall and not
just publishing it somewhere where we already publish per-mount
information?  e.g. in /proc/mounts?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2010-07-07  2:11 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 [this message]
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
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=20100707021150.GF25018@dastard \
    --to=david@fromorbit.com \
    --cc=adilger@sun.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=bfields@fieldses.org \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.