On Fri, Apr 28, 2017 at 8:56 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > On Fri, Apr 28, 2017 at 06:49:45AM +0100, Andy Whitcroft wrote: >> On Thu, Apr 27, 2017 at 03:30:35PM -0500, Eric Sandeen wrote: >> >> > It'd be trivial to make that a vfs function and set a flag on the vfs super >> > if the UUID is not unique. Would that be worthwhile? I can send a patch >> > if so. >> >> This only tells you that the UUID it has is unique now. As you are >> contemplating storing them in the FS they have to be unique in space >> _and_ time. No check you can do now can tell you if the UUID is unique >> for all time. Right ? > > Well, since we're talking about all time: "probably" :P > > That said, Eric was talking about a refactoring of one of XFS's mount > time checks that errors out if there's already a mounted fs with the > same uuid. We use it to avoid catastrophic mounting of the same fs from > multiple (misconfigured) multipaths/snapshots/volumes/whatever on the > same machine. Not sure if that's useful for Amir's case. > As far as I can tell, we don't mind that sb->s_uuid is not unique. All we care about is to verify that the file handle we are holding was encoded from the same file system instance OR from one of its derivative (LVM snapshot etc), just as a sanity that we won't get a completely different object (from a different fs type even) by mistake. If admin zygotes all his ext4 fs with the same uuid and fill them with different content and copies overlay layers between them.... Let me know if you think there is a real use case for this so I can sympathize. Amir. -- 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
