Re: Prepping to install: a different tangent

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

    Date:        Fri, 12 Jun 2015 09:12:54 -0453
    From:        "William A. Mahaffey III" <wam%hiwaay.net@localhost>
    Message-ID:  <557AE76F.7090701%hiwaay.net@localhost>


  | So, the question is: Do I indeed have 
  | to specify a spare drive explicitly in my raid.conf, or will raidctl 
  | intelligently decide to pick 1 & setup 'N-1' active devices for 'N' 
  | specified in the raid.conf file ?

You are confusing two different things, what you're thinking of as the "spare"
I think, is more correctly called the parity drive (and isn't actually
normally a physical drive, but is rotated around all the drives for different
slices of the raid - though I'm not sure if raidframe works that way).

Raid 5 needs N data drives + a parity drive to work - and to work effeciently,
N should be a power of two (like 2, or 4).

If a drive dies, data is reconstructed from the remaining N-1 drives, and
the parity (of course, when it is the parity that is dead, the data doesn't
need reconstructing).

A spare drive on the other hand is a completely unused drive, that just sits
around waiting for one of the other drives to die, at which point it replaces
that drive (automatically) and the raid continues to be fully operable
(allowing the dead drive to be replaced at leisure, and either become the
spare drive, or be reinserted into the raid set allowing the previously spare
drive to become spare again - which happens depends upon how the replacement
is inserted into the raid set).

With this setup, 2 drives can die, and the array continue functioning -
provided only that there is enough of a gap between the two deaths to allow
the spare drive to be correctly setup with all of the data that had been
on the drive that died first (two drives dying simultaneously, or close to
that, would still kill things.)

One (or more) spare drives like that make any raid (except raid0 of
course, which cannot recover from any failure) more robust - of course
at increased cost.

When you configured an explicit spare from one of your 5 drives, you
(as you calculated) made a 3 data + parity raid5 out of the remaining
4 drives - 3 is not a power of two, hence performance was degraded,
explaining why it too longer to initialise than the earlier time with
4 data + parity - and you had a spare drive in case one  of the other 4
died some time in the future.

Be aware that NetBSD raidframe does not autoconfigure spare drives,
if you're using raid autoconfig, the spare needs to be re-added after
each reboot.   Everything else works as expected, just after a reboot
the spare drive will just be "forgotten" until it is added back to the
raid set.

  | does a RAID5 setup really eat up as much storage as it looks like,

Ignore any spare drives, they're not really part of the raid set at
all,   Take whatever is left, reserve one drive for parity.   However
much is left is (minus a comparatively trivial amount of header) available
for data.   The 2.7TB you saw was 3 * 900GB (3 data drives, one parity,
and one spare).

kre

ps: I'd suggest you use something more likely to be unique than 1234567
as the serial number - a convention based upon the date and time (or
date and a counter of sets initialised that day - like 201506131 201506132,
or if you prefer 2015061309 for a set created about 9am).   Sticking to
that means that you won't accidentally use the same serial number for
some other set you create months from now when you've forgotten what
you used this time ... 1234567 is just too likely to be reused.  Of
course any other scheme you can expect will keep producing different
values for different raid sets will work just as well.   Be sure to keep
it to something that fits in 32 bits though.