Re: gptmbr.bin vs RAIDframe

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 17 Jun 2015 14:36:24 -0700
    From:        John Nemeth <jnemeth%cue.bc.ca@localhost>
    Message-ID:  <201506172136.t5HLaOGg020754%server.CornerstoneService.ca@localhost>

  |      Given that a GPT typically has a minimum of 128 slots, would
  | you do gpt->raid->gpt?  Why not just create a sufficient number of
  | RAID partitions?

Recovery workload.

Consider 2 drives, on which there are to be 30-40 filesystems, all mirrored.

One raid, with 40 partitions (wedges) on it is one possibility, 40 partitions
(wedges) each containing a raidframs, each containing a single filesystem is 
another.

When everything is working (and to some extent, initial config) there
is little real difference between those two approaches (the gtp->raidframs
way means more raidframe overhead but that is not really significant).

But when one of the drives dies, and is replaced, the raidframe->gpt way
requires (the operator) to arrange reconstruction of a single raid array
(issuing raidctl to add in the replacement) just once, the gtp->raidrame
way required doing that once for each of he raid arrays.

For me, that's enough to prefer fewer raid arrays.

Of course, if a drive develops bad spots, the single raidframe approach will
fail that drive, and none of the filesystems will be mirrored until the
drive is replaced or the bad spots corrected - the multiple raidframe approach
will only file the arrays where the bad spots occur, other filesystems
would remain mirrored.

kre