On 5/11/15 4:49 PM, Dave Chinner wrote: > On Mon, May 11, 2015 at 11:52:52AM -0500, Eric Sandeen wrote: >> On 5/11/15 11:14 AM, Brian Foster wrote: >>> On Fri, May 08, 2015 at 03:48:16PM -0500, Eric Sandeen wrote: >>>>> This adds a new superblock field, sb_meta_uuid. If set, along with >>>>> a new incompat flag, the code will use that field on a V5 filesystem >>>>> to compare to metadata UUIDs, which allows us to change the user- >>>>> visible UUID at will. Userspace handles the setting or clearing >>>>> of the incompat flag as appropriate, as the UUID gets written. >>>>> >>>>> If the incompat flag is not set, copy the user-visible UUID into >>>>> into the meta_uuid slot in memory; this is not written back to disk in >>>>> this case. >>>>> >>>>> The remainder of this patch simply switches verifiers, initializers, >>>>> etc to use the new sb_meta_uuid field. >>>>> >>>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> >>>>> --- >>> This all looks fine to me. The only thing that confuses me is why we >>> continue to use sb_uuid for the log. Eric points out on irc that we >>> can't modify the uuid when the log is dirty, so we can't actually break >>> anything in this manner. In other words, we effectively already handle a >>> modified uuid with respect to the log. >>> >>> That said, it seems inconsistent to me to create a metadata uuid field >>> and not use it for all metadata. My expectation from such a change is to >>> see sb_uuid now used only for user facing bits (e.g., mount and get geo >>> related) and sb_meta_uuid used everywhere else. Instead, we use sb_uuid >>> for the user facing bits, sb_meta_uuid for the internal bits that can't >>> handle a uuid change and sb_uuid for the internal bits that can. >>> >>> I suppose I could be convinced otherwise if there's context I'm missing, >>> but otherwise this seems a bit confusing to me... >>> >>> Brian >> >> Yeah, I'm sympathetic to that argument. I can look into using sb_meta_uuid >> for the log too, if the incompat flag is set. > > The log uuid is user facing, like the superblock uuid. i.e. there > are tools that identify external log devices by checking that the > uuid in the log matches the user facing uuid in the superblock. > Hence the log uuid needs to use the uuid that is reported to > userspace. None that are external to xfsprogs, I think, are there? (1) - but still. I'm happy to leave it as it is ... I don't think it really matters either way. -Eric (1) at one point I wanted to teach blkid to find an external log by UUID, but there is no "log superblock" so I gave up on that idea. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
