Re: swap-on-raidframe vs raidctl -P

[Greg Oster <oster%cs.usask.ca@localhost>]

der Mouse writes:
> I've just set up a 4.0 machine at work.  It's using raidframe for
> everything (well, not quite; there's a tiny boot partition that's not
> formally raided, though it is mirrored another way), and I saw a
> problem.
> 
> Swap is on raid0b, and, when raidframeparity ran, it complained that
> raid0 parity was dirty and started a parity rewrite.  

You have:

 swapoff=YES

in /etc/rc.conf , yes?  That should take care of most instances of 
this rewrite problem...

> This is hardly a
> catastrophe; the rewrite finishes fast enough that it's not a huge
> problem.  But it seems to me that this is suboptimal.
> 
> I see two possible fixes.
> 
> One would be a way to configure raidframe for uses (like swap) that
> don't care about data preservation when the partition is not in use;
> parity rewrite at boot would be dummied out for such partitions. 

This might work for RAID 1, but it will *not* work for RAID 5.

Consider a RAID 5 set, used for swap, where there is a stripe with
bad parity.  Let the blocks of that stripe be A, B, and P.  A "small 
write" to A will read P, compute P', and write out A' and P'.  Now 
consider that the disk containing A' dies.  B and P' will now be used 
to compute A'.  Unfortunately, P was not in sync with A and B 
initially, so B and P' cannot be used to compute the correct value of 
A'.  You end up swapping in 'garbage', and your system dies.

> (Only
> at boot; if a member fails and is replaced, the resulting rewrite
> should not be dummied out, at least not for blocks that have been
> written since boot - and keeping track of which blocks that is would be
> expensive enough that I'd be inclined to say it shouldn't be done.)
> 
> The other would be to run raidframeparity earlier, before swap is
> started.

I'm not sure what this would fix... whether or not swap is started on 
a partition matters not a wit to RAIDframe in determining whether a 
partition is in need of a parity check or not -- what matters is whether 
or not raidclose() got called on the last open partition on a RAID 
set at the last shutdown... 

> It seems to me that each should actually be done, independent of the
> other, but either one would be good enough for my purposes.  The former
> would be more intrusive as far as raidframe is concerned; I'm not sure
> the latter is possible, since I don't have my head around why it's run
> where it is now (rather than as part of raidframe).
> 
> Comments?
> 
> /~\ The ASCII                         der Mouse
> \ / Ribbon Campaign
>  X  Against HTML             mouse%rodents.montreal.qc.ca@localhost
> / \ Email!         7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Later...

Greg Oster