Re: Software RAID...
On Wed, 1 Aug 2001, Russell Coker wrote:
>
> The way RAID-5 works with 3 disks is to put blocks in the following order (X
> is an XOR parity block):
>
> 0 1 X
> X 2 3
> 4 X 5
> 6 7 X
> ...
>
> With 4 disks it will be the following:
> 0 1 2 X
> X 3 4 5
> 6 X 7 8
> ...
>
> So adding an extra disk would involve moving every block of data (apart from
> the first two). Now what happens if you experience a crash or power failure
> while doing such a re-build?
>
Well, moving the blocks of data should be pretty straightforward
then. You would have to recalculate every checksum block but as I see it,
it would be possible to do this on a row by row basis, and also keep a
working copy of every row + a counter on a different disk or possibly way
back on the new disk.
So if the old system looked like this
0 1 X
X 2 3
4 X 5
6 7 X
X 8 9
.....
During rebuild you would have this:
0 1 2 X
X 3 4 5
6 X 7 8 <- row you are writing
6 7 X Z Old raid + new empty blocks
X 8 9 Z
.......
As soon as you have traversed more than in this case 2 rows you would
not even need a backup copy of the blocks, only a counter of how far you
have gone. This would have to be held on disk though, and all disk writes
mush be synchronous to ensure that the data is safe in case of powerfail
or system crash. It should really be possible to do this rebuild in a
running raid system (if the rebuild process is done from the raid5 driver)
, as long as you keep track of how far the rebuild has gone and lock the
row in progress + in the beginning you need to lock the first rows from
access.
What I am worried more in this case is how the mke2fs optimisations for a
raid device will affect performance if you do this repeatedly, or will a
"defrag" of the raid device after this rebuid solve it?
/Roger
Reply to: