All of lore.kernel.org
 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
Date: Wed, 21 Apr 2004 17:34:35 +0000	[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





-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg\x12297
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

WARNING: multiple messages have this Message-ID (diff)
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: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-15  0:24 [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in Carl-Daniel Hailfinger
2004-04-15  0:24 ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6 Carl-Daniel Hailfinger
2004-04-15 14:08 ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support Thomas Horsten
2004-04-15 14:08   ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6 Thomas Horsten
2004-04-16 20:04   ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support Carl-Daniel Hailfinger
2004-04-16 20:04     ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6 Carl-Daniel Hailfinger
2004-04-17 17:35     ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support Carl-Daniel Hailfinger
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]
2004-04-21 17:34         ` Jeff Garzik
2004-05-01 16:31     ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support Wilfried Weissmann
2004-05-01 16:31       ` [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6 Wilfried Weissmann

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.