Re: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID supportin 2.6

[Jeff Garzik]

Carl-Daniel Hailfinger wrote:
> since on one side ATARAID support has vanished from 2.6 and on the other
> side some parties are pushing for an enhanced MD driver in the kernel, why
>  don't we do the setup and metadata handling of all those types of RAID in
> userspace?
>
> I got positive feedback by private mail from several kernel developers for
> the last incarnations of raiddetect, so if you disagree, speak up now.
>
> Raiddetect is a program to find vendor software RAID superblocks, analyze
> them for validity, group them by RAID vendor and (later on) set them up
> via MD/DM. It is small (~35kB compiled statically against klibc) and
> designed to be run from initrd/initramfs.
>
> raiddetect now supports the following metadata formats:
> -Promise RAID
> -Highpoint RAID
> -Medley RAID
> -Intel RAID

Yeah, it's pretty spiffy.  I like it.

My personal preference for raiddetect would be as a simple helper that 
examines the system, and outputs some information.

Then, someone using device mapper could use that in a script that takes 
the information generated by raiddetect, and uses it to configure 
DM-based raid0 and raid1 arrays.

Small and purpose-specific, and even usable for someone in a 2.4.x 
kernel that wrote a small MD-based plugin for "userspace-configured 
vendor raid [01]"


> If you want support for another metadata format, please tell me which and
> I'll try to add it. Patches are preferred ;-) My current wishlist is:
> - Adaptec ASR HostRAID
> - DDF RAID
>
> Hot-add and hot-remove features can be added easily if raiddetect is
> called by an udev rule on block device removal/insertion. If raiddetect
> stays loaded into memory or is allowed to save its state, hotplug events
> will not trigger any access to devices not related to that particular RAID
> array.

Well, hotplug and hotremove are more interrupt-context type events these 
days.  It's feasible to send "device just appeared" or "device is 
already gone, nyah nyah" messages to /sbin/hotplug after that fact, mainly.

Failover and hotplug/hotremove callbacks are definitely in-kernel 
things, IMO.  Userspace drives the policy behind that, of course.


> It seems that there are some host adapter drivers out there implementing
> their own RAID engine which could be consolidated into a single RAID
> "library" instead. If you know about such drivers, please speak up.

In the kernel long term, I would definitely like to see just a single 
piece of code for each raid flavor -- RAID0, 1, 5, 6, etc.

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/