Re: Software RAID5
Lennart Sorensen <email@example.com> writes:
> On Tue, Jun 06, 2006 at 09:25:48AM +0200, Goswin von Brederlow wrote:
>> I doubt that is ready yet. But other transformations are, raid5 with n
>> disks to n+1 disks and such. None of those will do filesystem
>> transformations and they don't need to. They just rearange the
>> underlying block device to the new scheme. If the device size changes
>> you have to resize the FS yourself.
> Rearanging the underlying blocks is a major job, and if interrupted in
> the middle, leaves a huge mess (unless it cleverly maintains the state
> of the data somewhere). The filesystem part on top is trivial to deal
> with afterwards.
Afaik it does consitently record all changes in the meta data so after
a crash it can just resume where it was. That, and doing it while the
disks are mounted, is the point of doing it in kernel after all.
> On the other hand, moving from raid5 with n disks to raid6 with n+1
> disks, ought to be easier, although still not trivial.
Actualy no. You have to rearange data blocks across more disks and
insert the 2nd parity blocks with no spare space being created. That
means you have to realy track every single block move. It might
actualy be better to convert to raid5 with n+1 disks moved to the back
of the disks with free space at the front and then to raid6 with n+1
When you resize raid5 from n to n+1 disks then you will end up with
more space. After the first few (first n blocks are crucial) blocks
you have a buffer of unused space between the chunk with n+1 disks and
the chunk with only n disks and you can rearange bigger and bigger
chunks in one go befor having to sync and note the changes in the
superblocks. At that point you can repeadately grow the n+1 disks
chunk, setup a mirror target and then shrink the n disks chunk from
the begining, which is a fairly easy task.
> Resizing raids is one of the few places a good hardware raid card seems
> to have an advantage.
Yeah. But we are getting there. :)
> Len Sorensen