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