Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263573AbUDURfH (ORCPT ); Wed, 21 Apr 2004 13:35:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263567AbUDURfH (ORCPT ); Wed, 21 Apr 2004 13:35:07 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:3456 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S263565AbUDURev (ORCPT ); Wed, 21 Apr 2004 13:34:51 -0400 Message-ID: <4086B0AB.1030604@pobox.com> Date: Wed, 21 Apr 2004 13:34:35 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl-Daniel Hailfinger CC: Linux Kernel Mailing List , Thomas Horsten , medley@lists.infowares.com, linux-hotplug-devel@lists.sourceforge.net, Wilfried Weissmann , Bartlomiej Zolnierkiewicz , Greg KH , Linux RAID Mailing List , Martins Krikis , ataraid-list@redhat.com, linux-scsi@vger.kernel.org Subject: Re: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6 References: <40803C61.503@gmx.net> <40816AEC.6020309@gmx.net> In-Reply-To: <40816AEC.6020309@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2762 Lines: 69 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/