[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: changing raid level?
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.
> 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
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.
Main Index |
Thread Index |