Jakob Østergaard wrote:
> I started hacking together a utility to allow resizing and eventually
> reconfiguration of RAID sets.
Kick ass. I had been thinking of doing the same thing, as I could have used
such a thing in the past. I gave it a shot on a mini-test raid0 setup i
made for it, and it seemed to work just fine... no compile issues, added the
partition no problem.
> The reason I'm writing about it now is, that I'd like to hear
> comments on the idea. Is it reasonable to use two raidtab files
> and a raid-device on the command-line, then try the conversion ?
> And what features would people like to see ?
The two raidtab way is what I would do as well. Handling command line
arguments to describe changes to the array might be simpler for some
operations (like /dev/md0 + /dev/sdc1) it would get horrible complex for
more detailed changes, as well as having to handle grammar for failed disks,
etc.
A fair thing to note is that this is a "riskier" endeavor than anything else
in the raidtools package. That being so, it makes sense to have a good
amount of checks along the way. I see you do check the raidtab against the
superblocks, which is most of it. I can't remember, though, if you do ext2
checking & mounted file system checking like mkraid does
Also, some thought needs to go into how this could handle a power fail in
the middle. Certainly you don't want the old raid set to auto start when
the machine is rebooted, doing so could cause all sorts of problems.
Instead of requiring users to disable the raid by removing the fd partition
labels, maybe the reconf utility should erase the superblocks on the md
device it's working on, placing instead a marker that shows it's in the
middle of being reworked. If status information about the reconstruction
was kept in the superblocks (or just one) the reconf utility could use this
data to pick up where it left off...
Also, when allowing a user to reduce the raidset size ( can't remember if
you already allow this... I read the code sunday and already I've forgotten
everything ;), you probably want to do a sanity check to see if the ext2
partition on that device has already been sized down.
Might also benefit in considering what happens if there's a hardware error
on one of the old or new disks during the process... perhaps an area of bad
sectors on one of the new disks? I think all of the information is still
there at this point to do an about face, and start un-reconf'ing the
drive... walking backwards to put it back in it's original state.
I believe in put-up or shut-up, so I'm happy to lend my time to the process.
I'm in between consulting gigs right now and could probably add something.
Great work, thanks much.
Tom