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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
