linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Horsten <thomas@horsten.com>,
	medley@lists.infowares.com,
	linux-hotplug-devel@lists.sourceforge.net,
	Wilfried Weissmann <Wilfried.Weissmann@gmx.at>,
	Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	Greg KH <greg@kroah.com>,
	Linux RAID Mailing List <linux-raid@vger.kernel.org>,
	Martins Krikis <mkrikis@yahoo.com>,
	ataraid-list@redhat.com, linux-scsi@vger.kernel.org
Subject: Re: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6
Date: Wed, 21 Apr 2004 13:34:35 -0400	[thread overview]
Message-ID: <4086B0AB.1030604@pobox.com> (raw)
In-Reply-To: <40816AEC.6020309@gmx.net>

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




      reply	other threads:[~2004-04-21 17:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.40.0404151458450.30892-100000@jehova.dsm.dk>
     [not found] ` <40803C61.503@gmx.net>
2004-04-17 17:35   ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6 Carl-Daniel Hailfinger
2004-04-21 17:34     ` Jeff Garzik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4086B0AB.1030604@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=Wilfried.Weissmann@gmx.at \
    --cc=ataraid-list@redhat.com \
    --cc=c-d.hailfinger.kernel.2004@gmx.net \
    --cc=greg@kroah.com \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=medley@lists.infowares.com \
    --cc=mkrikis@yahoo.com \
    --cc=thomas@horsten.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).