On Tue, May 2, 2017 at 4:47 PM, Christoph Hellwig <hch@xxxxxx> wrote: > 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@xxxxxx> 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. Two separate issues: a) is s_uuid unique across all currently mounted filesystems on this system b) is s_uuid unique for all different filesystems that have been mounted at one time on some system We can check (a) but not (b). But failing (b) could have equally bad consequences as failing (a). Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
