Linux RAID management utilities?

Bill McGonigle bill at bfccomputing.com
Wed Sep 26 13:33:06 EDT 2007


On Sep 25, 2007, at 23:13, Paul Lussier wrote:

> Bill McGonigle <bill at bfccomputing.com> writes:
>
>> If it exists - kernel auto-assembly is fun for the lazy (I always get
>> burned if I try to get fancy with it, though).
>
> Fancy like how?  I've been using kernel auto-assembly for years
> without problems on raid sets with raid levels 0,1,3, and 5.

For example, on Fedora-based machines anyway, none of my RAID-10  
stuff starts at boot time.   I have to write a bash script to detect  
and start it.  It can't work out, apparently, that it has to start / 
dev/md6 and /dev/md7 (each a RAID-1) before it can make /dev/md3 (a  
RAID-0 of them).

Some of this also seems to be dependent on the kernel not quite  
grocking USB-attached drives, udev apparently has to be running,  
though I've also seen it on e.SATA drives, so that's not entirely  
it.  I don't understand why the kernel sometimes forgets a member of  
an e.SATA array at boot time when there are never any other problems  
with the array.  Open problem.

>> Then there's the problem of mdadm.conf says it's UUID-12345... but I
>> have to go to /sys to get that
>
> Huh ?  Any drive which is part of a raid set will tell you what the
> UUID is.  The md device, if it's active will also tell you.

Sure, that's how I do it now.  I just don't want to.  I want to tell  
the RAID system, "go find the extra mirror drives that are currently  
orphaned and put them into their RAID sets."  I want to script that  
so when I bring my backup mirrors back onsite I just plug them in and  
it goes.  If a udev event fired off that kind of assembly, bonus.   
That script needs to run based on UUID's, but I don't want to think  
about them, that's the computer's job.

>> Also, some information is only in fstab, like what gets mounted  
>> where.
>
> Well, yeah, that's what the file system table is for.
> I have to admit, I'm very confused about what you're asking for.
> Your initial request was to provide you with something which, and I  
> quote:
>
>   "rebuild the raid arrays with missing members based on UUID",
>
> mdadm is that tool.  So, what's fstab got to do with anything?  File
> systems and md devices have little to do with each other.  There isn't
> necessarilly a 1:1 correlation between a raid set and a file system.

Example:   I have 6 bare drives not in any arrays.  Assemble the  
arrays correctly and mount any filesystems represented by those  
arrays.  So, there's enough information in mdadm.conf, fstab, and / 
sys to do that.  As far as I can tell, no tool does that  
automatically.  It absolutely wouldn't apply in every case, and of  
those six drives, maybe only two drives satisfy a solution to the  
problem.  The right tool can figure this out.

> It's entirely possible, and not entirely unreasonable to have one raid
> set be part of another raid set (often called "plaiding") (though,
> off-hand, I don't know if this is supported under mdadm...).

Yeah, that's how I do RAID-10.  There's no special semantics in  
mdadm.conf, which is either good or the problem, depending on  
perspective.  For example, from one of my servers:

ARRAY /dev/md3 level=raid0 num-devices=2 uuid=242c636a: 
30e5e28b:c1d50577:0d77e926
ARRAY /dev/md6 level=raid1 num-devices=2 uuid=e6337fcf: 
15248b1d:ab7fe992:8501be80
ARRAY /dev/md7 level=raid1 num-devices=2  
uuid=86350f71:6f972826:7c7b24c7:46ae812b

It's not apparent there that md6 and md7 make up md3 from  
mdadm.conf.  But this is all discoverable in /sys.  Currently that's  
a manual process, the rc scripts don't know how to deal with this  
level of complexity.  I haven't thought too much about the strategy  
(I want somebody else to have done it already, after all!) but it  
might need to be stored in a dependency graph and then solved.  Time  
to dust off 'Algorithms"...

> Also, mdadm.conf is seldom, if ever used in my experience.  Though  
> it's
> not a bad place to stash the information for future use.  The mdadm
> man page even gives a decent example of how to discover all this:

It appears to be essential for doing 'mdadm --auto=md', which I need  
to do in my rc scripts to make up for those deficiencies in the stock  
rc scripts and udev.  I believe mdadm.conf shouldn't have to exist  
today, all the same info is under /sys.  Ideally we don't make the  
admin do busywork... but currently he has to.

Unfortunately, this effectively means the difference between an out- 
of-the-box Linux NAS that a user can manage and something a sysadmin  
has to handle.  That's fine for thinking work, but this is drudgery.   
I recently had to buy a $500 3Ware RAID card for a client, just  
because it can auto-rebuild a mirror and linux can't (I sure don't  
want to drive up there to swap drives).  Bo-o-o-o-o-gus (apologies to  
Click & Clack).

-Bill
----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf



More information about the gnhlug-discuss mailing list