[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: changing raid level?
der Mouse writes:
> Okay, I've got a 4.0.1 machine with a RAID 0 configured:
> # raidctl -G raid1
> # raidctl config file for /dev/rraid1d
> START array
> # numRow numCol numSpare
> 1 2 0
> START disks
> START layout
> # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_0
> 128 1 1 0
> START queue
> fifo 100
> I want, for reasons irrelevant here, to change this to a RAID 1 [%].
> So I create a conf file just like the above, except the layout section
> says "128 1 1 1". I run "raidctl -u raid1" to unconfigure the old raid
> and "raidctl -C new-config-file raid1" to configure the new.
You havn't run "raidctl -I 122345 raid1" yet, right?
> But, when I check, the newly-configured raid1 is still raid level 0,
> not the level 1 I want! Apparently the RAIDframe administrative data
> on the disks overrides the config file. This seems wrong to me; with
> -c, I'd expect this to be a fatal error, and with -C, the config file
> to override. (I tried using -c to configure the new raid1 too, and it
> works the same as -C.)
'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... (in particular, they don't know
what new serial number you want to use..)
> Is there some reason it was done this way, or should I send- it -PR, or
> what? For the moment, I'll destroy the first meg or so of raid2e and
> raid3e, which I expect will make -C work the way I want....
-C will work the way you want.. you just need to keep going with the
> [%] Because of other changes, redundancy becoems more important than
> space. (The use of RAID as the underlying units is for easy disk
> replacement and protection against disk reordering; raid2 and raid3
> are one-member RAID1s, set autoconfiguring.)
Main Index |
Thread Index |