linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: travis+ml-linux-raid@subspacefield.org
To: Chris Murphy <lists@colorremedies.com>
Cc: Phil Turmel <philip@turmel.org>, Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: bootsect replicated in p1, RAID enclosure suggestions?
Date: Thu, 25 Aug 2016 20:11:16 -0700	[thread overview]
Message-ID: <20160826031116.GP32250@subspacefield.org> (raw)
In-Reply-To: <CAJCQCtQyqH2eOmyqmpz0sZzD9ia4Q8RsA8eb+6inuDY6QP+Tyg@mail.gmail.com>

On Thu, Aug 25, 2016 at 08:48:24PM -0600, Chris Murphy wrote:
> Right, so something like GPT on /dev/sda and /dev/sdb to create sda1
> and sdb1, then mdadm -C /dev/md0 --metadata=1.0 ... /dev/sda1
> /dev/sdb1, and then create a GPT on /dev/md0. The result is /dev/md0,
> /dev/sda1, and /dev/sda2 will all appear to have the same GPT on them.
> 
> I would say that's probably a bad idea, I know some tools allow it,
> but it creates an ambiguity. It could be argued to be inconsistent
> with the UEFI spec. The only nesting it describes is MBR on a GPT
> partition, not GPT nested in a GPT partition. This is probably also
> better done using LVM. Otherwise we get nutty things...

We had similar ambiguities in MBR-land, if you set the active flag on
more than one partition, or if you have more than one extended
partition.

Since the behavior in those cases is undefined, it seems wise to avoid
creating them.

Better if the specification avoids these situations - that no
combination of bits can create an ambiguous interpretation - but in
the occasional cases where that can't be avoided you're best off not
creating those situations.
-- 
http://www.subspacefield.org/~travis/ | if spammer then john@subspacefield.org
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977

  reply	other threads:[~2016-08-26  3:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  5:09 bootsect replicated in p1, RAID enclosure suggestions? travis+ml-linux-raid
2016-08-24  2:14 ` travis+ml-linux-raid
2016-08-24 17:15 ` Chris Murphy
2016-08-25  6:25   ` travis+ml-linux-raid
2016-08-25 21:06     ` Wols Lists
2016-08-25 22:32     ` Chris Murphy
2016-08-26  2:33       ` Phil Turmel
2016-08-26  2:48         ` Chris Murphy
2016-08-26  3:11           ` travis+ml-linux-raid [this message]
2016-08-26  2:50       ` travis
2016-08-26  3:21         ` Chris Murphy
2016-08-26  3:58           ` travis
2016-08-26  4:06             ` travis+ml-linux-raid
2016-08-26  4:25               ` Chris Murphy
2016-09-02  2:18                 ` travis+ml-linux-raid
2016-09-01 17:22 ` Wols Lists
2016-09-01 23:10   ` Chris Murphy

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=20160826031116.GP32250@subspacefield.org \
    --to=travis+ml-linux-raid@subspacefield.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=philip@turmel.org \
    /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;
as well as URLs for NNTP newsgroup(s).