From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Martins Krikis <mkrikis@yahoo.com>
Cc: linux-kernel@vger.kernel.org, marcelo.tosatti@cyclades.com
Subject: Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3
Date: Sun, 10 Oct 2004 01:44:23 +0200 [thread overview]
Message-ID: <58cb370e04100916441c1b74d@mail.gmail.com> (raw)
In-Reply-To: <20041009230300.75239.qmail@web13724.mail.yahoo.com>
On Sat, 9 Oct 2004 16:03:00 -0700 (PDT), Martins Krikis
<mkrikis@yahoo.com> wrote:
> --- Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl> wrote:
>
> > I may sound like an ignorant but...
> >
> > Why can't device mapper be merged into 2.4 instead?
>
> "Instead" is the key word here... That would mean that
> Boji's and my work has been largely in vain and that the
> driver that to my best knowledge currently provides the
> simplest (from a user's point of view) cooperation with
> Intel RAID OROM and the most comlete feature-set regarding
> Intel RAID metadata interpretation and updates would not
> make it to the kernel. I have nothing against device mapper
> being merged into 2.4 but I don't consider that a fair
> reason for not considering iswraid.
Well, in some way this speaks against merging iswraid in 2.4.
If it provides "the most comlete feature-set regarding Intel RAID
metadata interpretation and updates" then merging it would
create regression when compared to 2.6, wouldn't it?
> > Is there something wrong with 2.4 device mapper patch?
>
> I don't think so. However, I do believe that iswraid has
> some advantages, one of them being the ability to just link
> it statically with the rest of the kernel and not needing
> any user-space support code, i.e., initrd is not necessary.
Yep, no doubt it is easier to use but harder to maintain.
> Also, I do not believe that dm+dmraid are currently
> capable of updating the Intel RAID metadata in case of
> errors. Please correct me if I'm wrong.
again "regression" argument is valid here
> > It would more convenient (same driver for 2.4 and 2.6)
> > and would benefit users of other software RAIDs
> > (easier transition to 2.6).
>
> If you expect the transitioning from ataraid to dm+dmraid
> to be so hard that it is best to do it separately from
> the switch to a 2.6 kernel, then I think 2 things are true:
Maybe not hard but inconvinient.
> 1) there might be something positive about the simple
> usage of ataraid subdrivers,
Yep.
> 2) the users of Intel RAID metadata might benefit by
> having two drivers supporting them in 2.4 kernels---the
> one with the "simple, ataraid-style" usage and "the one
> for the future".
Yep.
> My email archive and the feedback on iswraid's project
> page actually contains many requests for an iswraid port
> to 2.6. Which I'm reading as a sign that some users
> actually like it.
iswraid and 2.6 is a no go for obvious reason (no ataraid)
> The main features of iswraid are listed in
> Documentation/iswraid.txt, almost at the top of the file.
> I believe that several of them distingiush it from
> other ataraid subdrivers in a positive way, and there
> was certainly a lot of hard work that went into this driver.
No doubt about that.
I'm fine with merging iswaid into 2.4 but it is a bit shame that
the same amount of work didn't go into improving Intel RAID
support in 2.6.
> I don't know how dm+dmraid would compare, but if you do,
> I'll be most interested to learn about it.
>
>
>
> Martins Krikis
> Storage Components Division
> Intel Massachusetts
next prev parent reply other threads:[~2004-10-09 23:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87d5zzfds7.fsf@yahoo.com>
2004-10-09 20:44 ` [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3 Martins Krikis
2004-10-09 21:37 ` Bartlomiej Zolnierkiewicz
2004-10-09 22:07 ` Jeff Garzik
2004-10-09 23:22 ` Bartlomiej Zolnierkiewicz
2004-10-09 23:36 ` Jeff Garzik
2004-10-09 23:50 ` Bartlomiej Zolnierkiewicz
2004-10-11 11:19 ` Marcelo Tosatti
2004-10-12 14:56 ` Martins Krikis
2005-01-18 17:28 ` iswraid and 2.4.x? Martins Krikis
2005-01-18 15:05 ` Marcelo Tosatti
2005-01-18 18:13 ` Jeff Garzik
2005-01-18 15:13 ` Marcelo Tosatti
2005-01-18 18:34 ` Jeff Garzik
2005-01-18 19:56 ` Martins Krikis
2005-01-18 20:55 ` Bartlomiej Zolnierkiewicz
2005-01-18 21:14 ` Jeff Garzik
2005-01-18 21:17 ` Bartlomiej Zolnierkiewicz
2005-01-18 21:59 ` Martins Krikis
2004-10-09 23:03 ` [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3 Martins Krikis
2004-10-09 23:44 ` Bartlomiej Zolnierkiewicz [this message]
2004-10-09 23:54 ` Jeff Garzik
2004-10-10 1:00 ` Martins Krikis
2004-10-10 2:06 ` Bartlomiej Zolnierkiewicz
2004-10-10 2:40 ` Martins Krikis
2004-10-10 18:19 ` Alan Cox
[not found] <bc8bcc5104100918206842d6d3@mail.gmail.com>
2004-10-10 2:08 ` Martins Krikis
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=58cb370e04100916441c1b74d@mail.gmail.com \
--to=bzolnier@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=mkrikis@yahoo.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.