Re: changing raid level?

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

der Mouse writes:
> >> 'raidctl -s' gets the info from the component labels, which, if you
> >> havn't run 'raidctl -I', havn't been updated yet...  The in-core
> >> setup is what you want, but the component labels on the disk havn't
> >> yet been updated to reflect that...
> > Hmm, perhaps I was just confused by raidctl -c's failure to error
> > out.  Thanks for the clout with the cluestick; I'll see if -I fixes
> > things.
> 
> This is weird.
> 
> I unconfigured raid1, destroyed the first 10M of each member again, put
> the config file back to RAID level 0, and reconfigured it that way (-C,
> -I, and -i - the last being fast for level 0).

Ya... for RAID 0 it's a NOP.

> Then, I unconfigured that, changed the config file back to level 1, did
> _not_ destroy the beginning of the disks, and used -c (not -C).  It
> succeeded.  So I used -I, and sure enough, raidctl -s now reports it as
> level 1.
> 
> The weird part: I then used -i, and started watching with raidctl -S.
> Based on the ETAs, the -i rebuild is happening about five times as fast
> as it was when I did destroy the beginning of the disks (the ETA is
> about 7 hours instead of 38).  I'll see what happens to the ETA as it
> runs (early estimates are often pretty wrong), but this difference is
> so dramatic it's hard to believe it's entirely mis-estimation.

My guess is it slowed down significantly again...  The basic 
algorithm used for this is: 

  read unit from component A, read unit from component B
  If data read is different, then write what was read from A onto B.

So where the components are already in-sync (e.g. where the -i 
rewrite has already happened) all that needs to be done are the reads 
and the compare.  Where they arn't in sync, it actually needs to 
write out stuff, which slows things down a fair bit...

Later...

Greg Oster