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

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

[Carl-Daniel Hailfinger]

[crossposting this to hopefully relevant lists]
Hi,

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

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.

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.

The following issues remain still to be sorted out:

Carl-Daniel Hailfinger wrote:

> Greg: Would you accept this patch into your udev package?
> 
> Thomas Horsten wrote:
> 
>>On Thu, 15 Apr 2004, Carl-Daniel Hailfinger wrote:
>>
>>
>>>What I need:
>>>- Criticism of coding style/ missing abstraction
> 
> 
> I got a mail from Barlomiej Zolnierkiewicz where he suggested to split the
> vendor dependent code out of raiddetect.c. This will happen in one of the
> next revisions.

This is on hold until I receive feedback from Greg K-H whether this will
be accepted into udev or not.


>>>- People checking the numerous FIXMEs
> 
> 
> I now have the following FIXMEs (aka "I have no idea about it"):
> - 5 FIXMEs in the Medley RAID code. Thomas, could you comment once you're
> back?
> - 3 FIXMEs in the Highpoint RAID code. Wilfried, could you please take a
> look at them?
> - 2 FIXMEs in the Promise RAID code. I will work on those myself.
> 
> - some generic FIXMEs:
>   - Is the sector size of a harddisk always 512 bytes?
>   - Is /sys/block/*/size always in 512-byte units?
>   - Are there controllers out there which occupy more than one PCI device?
>   - How can I find out if a block device under /sys/block is a disk?

Do you have an idea about the generic FIXMEs listed above?


>>>- Help with sorting out who owns which copyrights
> 
> This is still a _big issue_.

Since the patch is already too big (~42kB) for some mailing lists, please
get the latest version from
http://www.hailfinger.org/carldani/linux/patches/raiddetect/

The patch is against the latest udev bitkeeper tree and applies fine to
udev-024 if you prefer working with officially released versions.


Regards,
Carl-Daniel

Re: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 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