Neil Brown wrote:
> >
> > The first is --analyze or -Z. It's a cross between
> --detail and --examine
> > (from which the code is taken, of course). Given a device,
> it tries to
> > figure out the status of the RAID it is a part of, and its
> state within the
> > RAID, and condense it to a terse one line output. I use it for
> > scripting.
>
> I'm having difficulty figuring out exactly what the modivation for
> this is, so it's hard to say just what I think of it.
> It is almost like a varient of the new
> mdctl --examine --scan
> The differences being that:
> - You only report one array, the one that has the nomiated device.
> - You report if the array is active or not
> - You report the state of each componenet device.
>
The motivation for it is mostly for "hot swap" scripting. When a device is
inserted that may or may not be a member of a RAID, active or not, what do
you do with it?
If it's not part of an array ("UNINITIALIZED") no need to do anything with
it.
If it's part of an inactive array, and you have enough drives to start the
array up now, you can start it up.
If it's part of an active array that's degraded, you may want to integrate
it.
If it's part of a healthy array, you may want to spare-ify it.
By examining a superblock on a device, you can tell what *it* thinks of the
RAID. By examining the state of an active RAID, you can tell what it thinks
of the device. I was trying to combine the two, with the bonus of
identifying how many members of any inactive RAID are present.
I'm not terribly happy about the form of the output, though.
> Possibly the state information could be added to the output of
> mdctl --examine --brief
> as comments (so that they are syntactically acceptable in the config
> file, and if explicit devices are given with
> mdctl --examine --scan
> then only arrays containing those devices are reported.
> Would that work for you?
>
Would that have the array status in it?
> >
> > The second is --assemble-using or -U. It's an --assemble
> command for the
> > lazy. Given a device, it pulls the UUID off it and then
> uses it for the
> > --assemble command. I basically use this to loop through
> the devices in
> > mdctl.conf and start the arrays connected with them
> automatically at startup
> > time. I don't have to keep track of the UUIDs this way.
>
> You needs someway of keeping track of which array is which.
> With 0.6, you can use super-minor= if you are sure you wont
> have drives
> imported from other machines, or devices= if you are sure that device
> names wont change.
> I suspect that with 0.6 an mdctl.conf file like
>
> DEVICES /dev/hd?* /dev/sd?*
> array /dev/md0 super-minor=0
> array /dev/md1 super-minor=1
> array /dev/md2 super-minor=2
> array /dev/md3 super-minor=3
> array /dev/md4 super-minor=4
> array /dev/md5 super-minor=5
>
> would work for you.
> You could even try:
>
> echo 'DEVICES /dev/hd?* /dev/sd?*' > /etc/mdctl.conf
> mdctl -Es >> /etc/mdctl.conf
> mdctl -As
>
> and pick up everything that way.
> However if you got any stray devices with raid superblocks coming into
> your system, this would fall apart.
>
That looks pretty much like my mdctl.conf, except I call out the devices
explicitly. You are right that a stray device with raid superblocks would
cause problems (assuming it can start -- a one drive RAID or a mirror part,
for instance) if it grabbed the wrong minor.
I guess my thinking is that it could be easier to identify the devices that
belong to a system, and just start the RAIDs on them, than to explicitly
track the RAID uuids that belong. This isn't going to be always true, or
even generally true. But I have a test box where I never really move the
devices around but I create and destroy RAIDs reasonably frequently. Also
with hot swap I think it's kind of nice to say "start the RAID referenced on
this device" too.
I think it's kind of nifty to be able to assemble the RAID mentioned on this
drive, rather than grabbing the UUID using -E and then start it up using
that. As you showed, it doesn't provide any new functionality, it just
shortens the steps into one.
> >
> > Of course, starting up all the RAIDs connnected with the devices in
> > mdctl.conf makes it tough to keep a RAID from starting. So
> the third is
> > --destroywithextremeprejudice (no short option for this
> one). All it does
> > is zero out the RAID superblock on a device. It's not
> smart at all (for
> > instance, it should probably make sure the RAID isn't
> active before it
> > zeroes it...). But it is handy for killing stopped RAIDs :->.
>
> I'm pretty happy with this one. I like the lack of a short option.
> But I like hyphens between words, and I think that
> --destroy-with-extreme-prejudice
> is just a little bit too long.
> What would you think of:
> --erase-superblock
>
> I might put that in and do a 0.6.1.
>
I like it, though it's not as colorful a name :->
Dale Stephenson
steph@snapserver.com
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
