Re: changing raid level?

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

der Mouse writes:
> >> 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 [...]
> > My guess is it slowed down significantly again...
> 
> Turns out yes, it did.
> 
> > 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.
> 
> Heh.  Raidframe keeps surprising me.  That would explain it; it was
> very fast while reading the portion that the previous run updated.

Right.

> I was expecting this would be a simple "copy from A to B" operation; I
> guess someone (a) optimized for the common case of almost-up-to-date
> and (b) thinks reads are better (faster, or whatever) than writes.

Right.  That, and with proper setup, the same algorithm can be scaled 
to work with an n-disk RAID 5 set.  That is: 
  read n-1 data units, read parity unit
  compute parity
  If computed parity is different than read parity, write new parity

For a RAID 1 set, the "parity unit" is simply the second disk, and 
computing that parity requires no further computations.

> Next time I have occasion to add a not-nearly-up-to-date member to a
> raid 1, I'll copy data myself first.  (I have a program that copies
> data rather like simple use of dd, but overlaps reads and writes for
> better speed - and in many cases it does run substantially faster.)

Well... you could just hot-add the disk, and do a reconstruct... That 
will do a simple read+write, rather than a read+read/compare/write.

Later...

Greg Oster