Encrypting raid5 volume with geli

[Rick C. Petty]

On Fri, Dec 12, 2008 at 02:08:49PM +0100, Ulf Lilleengen wrote:
> > 
> > It doesn't have to be "weird" behaviour, depending on whether gvinum
> > checks parity on reads (does it?). If it does, it will only have to
> > ignore checksum errors in this case.
> It does check parity on reads. But I think it doesn't matter, since no sane data
> has been written in that block anyway. 
> 
> But as you say, one way to handle it is to ignore the checksums if the data
> is known to not be initialized, but then wouldn't one have to keep track of
> which blocks have a valid parity and which who does not?

IMO, trying to read a block that hasn't been initialized is perfectly
acceptable as an "error".  I would just mark the volume as up.  Chances are
a sane admin would be writing to the blocks before reading the same blocks
(except in the disk test scenario, in which case why are they bothering
with a raid5?).  If a read happens on a block that hasn't been written to,
it is a parity error.  The real question is what happens when parity errors
happen.

I guess I suggest allowing you to force the plex up (via setstate) if you
are pretty confident reads will only happen after writes (which is the case
after newfs-ing the volume).  In either case, always mark the volume as
up..  the plex can be in a degraded state, meaning the parity has failed
but reads can still happen.  It sounds perfect to me; the states reflect
the actual state of things.

-- Rick C. Petty