Re: [PATCH v2] xfs: publish UUID in struct super_block

[Christoph Hellwig <hch@lst.de>]

On Tue, May 02, 2017 at 05:27:36PM +0300, Amir Goldstein wrote:
> On Tue, May 2, 2017 at 5:17 PM, Christoph Hellwig <hch@lst.de> wrote:
> > On Tue, May 02, 2017 at 05:13:56PM +0300, Amir Goldstein wrote:
> >> How can it create problems if uniqueness is not guaranteed with
> >> Current s_uuid? Even if we did make the xfs uuid table code generic
> >> It couldn't be the vfs default. Filesystems will have to opt in.
> >
> > It creates problems if you e.g. mount an ext4 fs and a dm snaphot of
> > it.  The non-XFS file systems are simply buggy in this regard.
> >
> > Non-uniqueue uuids are an absolute no-go.
> 
> I'm not sure I follow your specific concern here.
> Surely you are not proposing to get rid of the nouuid
> mount option, are you? So what's the point of hiding
> the fact that there are 2 mounted filesystems with the
> same uuid from VFS?

Because it breaks people using s_uuid.  Take a look at cleancache,
which identifies a pool with it.  Once you have to snapshot with
the same uuid the pool concept is broken.  Same for any sort of
use in file handles.

The U in UUID stands for unique, and we must ensure that's actually
true.

> 
> Because that is the the only implication of exporting
> s_uuid regardless of nouuid mount option.
> 
> Whether or not ext4 and other fs should restrict
> multi mount of same uuid is a completely different
> issue.

It's not.  The whole point of exporting s_uuid is to have a uniqueue
identifier for a superblock.  If it's not actually uniqueue there is
no point in having or using it.