Re: Additional options for mdctl-0.5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday March 7, dstephenson@snapserver.com wrote:
> The release of 0.6 reminded me that I had some changes to mdctl-0.5 I hadn't
> sent on to the list.  I added three options to mdctl which I've found to be
> handy.  I'm not claiming they will be useful to others, or that they're a
> good idea to add to mdctl.  YMMV.

Thanks for this.  I'm sure we will find some of it useful.

> 
> 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.

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?

> 
> 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.

> 
> 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.

NeilBrown
-
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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux