From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Eric Sandeen <sandeen@sandeen.net>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 1/2] xfs: create new metadata UUID field and incompat flag
Date: Tue, 12 May 2015 07:11:45 -0400 [thread overview]
Message-ID: <20150512111144.GA34423@bfoster.bfoster> (raw)
In-Reply-To: <20150511214902.GG15721@dastard>
On Tue, May 12, 2015 at 07:49:02AM +1000, 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@redhat.com>
> > >> > ---
> > > 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.
>
Ok, sounds good. Thanks for the explanation.
Brian
> > I had skipped it just because that use of the UUID predated the CRC changes.
>
> Changing the uuid results in the log being zeroed, so the uuid in
> the log can be changed without issue, even if we are using CRCs.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-05-12 11:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 20:40 [PATCH 0/2] allow UUID changes on V5/CRC filesystems Eric Sandeen
2015-05-08 20:48 ` [PATCH 1/2] xfs: create new metadata UUID field and incompat flag Eric Sandeen
2015-05-11 16:14 ` Brian Foster
2015-05-11 16:52 ` Eric Sandeen
2015-05-11 21:49 ` Dave Chinner
2015-05-11 23:50 ` Eric Sandeen
2015-05-12 1:58 ` Dave Chinner
2015-05-12 11:11 ` Brian Foster [this message]
2015-05-08 20:59 ` [PATCH 2/2] xfsprogs: Add new sb_meta_uuid field, and userspace tools to manipulate it Eric Sandeen
2015-05-08 21:14 ` Eric Sandeen
2015-05-08 21:49 ` [PATCH 2/2 V2] " Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
2015-05-12 19:24 [PATCH 0/2 V3] allow UUID changes on V5/CRC filesystems Eric Sandeen
2015-05-12 19:27 ` [PATCH 1/2] xfs: create new metadata UUID field and incompat flag Eric Sandeen
2015-05-14 13:36 ` Brian Foster
2015-05-14 22:36 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150512111144.GA34423@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox