From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>,
Brian Foster <bfoster@redhat.com>, 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 11:58:27 +1000 [thread overview]
Message-ID: <20150512015827.GS4327@dastard> (raw)
In-Reply-To: <55514028.6010606@sandeen.net>
On Mon, May 11, 2015 at 06:50:00PM -0500, Eric Sandeen wrote:
> 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:
> >>> 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.
Well, we don't know, really, do we? It's best to play it safe and
keep it the same as the user visible filesytem uuid, as that is
what is currently expected by anything poking at block dev UUIDs...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-05-12 1:58 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 [this message]
2015-05-12 11:11 ` Brian Foster
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=20150512015827.GS4327@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.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