On Fri, Feb 09, 2018 at 08:11:44AM +1100, Dave Chinner wrote: > On Thu, Feb 08, 2018 at 08:31:21AM -0600, Eric Sandeen wrote: > > > > > > On 2/8/18 2:25 AM, Dave Chinner wrote: > > > On Wed, Feb 07, 2018 at 09:53:40PM -0800, Darrick J. Wong wrote: > > >> On Wed, Feb 07, 2018 at 08:35:12PM -0600, Eric Sandeen wrote: > > >>> > > >>> > > >>> On 2/6/18 12:11 AM, Dave Chinner wrote: > > >>>> On Mon, Feb 05, 2018 at 04:37:22PM -0600, Eric Sandeen wrote: > > >>>>> > > >>>>> > > >>>>> On 2/5/18 4:36 PM, Dave Chinner wrote: > > >>>>>>> In retrospect I think we (I) should have left the "metadata" uuid as > > >>>>>>> the one to match the log, not the user-facing one. > > >>>>>> I suspect we can just change the log recovery code to accept either > > >>>>>> sb_uuid or sb_metauuid if the metauuid feature bit is set and > > >>>>>> change xfs_db to not rewrite the log when metauuid is used.... > > >>>>>> > > >>>>>> Cheers, > > >>>>> > > >>>>> That was my first thought, but then newer userspace UUID changes > > >>>>> won't be mountable on older kernels. I don't think we can just > > >>>>> change it w/o some thought re: compatibility... > > >>>> > > >>>> So maybe we should use a log incompat bit and provide an alternative > > >>>> command for the old way of changing the UUID in the log? > > >>> > > >>> Sure, if we're happy burning an incompat bit for this, sounds good. > > >> > > >> Or a log incompat bit? > > > > > > That's what I suggested :P > > > > And that's what I /meant/, sorry for the lack of specificity ;) > > So we are all happy to burn a log incompat bit for this? > > /me wonders how many one liners we can string this out into :) I thought we were doing haiku to approve patch ideas now. :( --D > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- > 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 -- 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
