Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Martins Krikis]

--- Martins Krikis <mkrikis@yahoo.com> wrote:

>   Martins Krikis
>   Storage Components Division
>   Intel Massachusetts

While it's a bit late for that, my previous post had a
serious signature error. The correct one is this:

    These opinions are solely mine and
    may not agree with those of my employer.

    Martins Krikis

My apologies to whomever I may have mislead in thinking
otherwise... And for wasting so much bandwidth.

  Martins Krikis



		

[Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Martins Krikis]

Version 0.1.4.3 of the Intel Sofware RAID driver (iswraid) is now
available for the 2.4 series kernels at
http://prdownloads.sourceforge.net/iswraid/2.4.28-pre3-iswraid.patch.gz?download

It is an ataraid "subdriver" but uses the SCSI subsystem to find the
RAID member disks. It depends on the libata library, particularly the
ata_piix driver that enables the Serial ATA capabilities in ICH5/ICH6
chipsets. Hence, for kernels older than 2.4.28, the libata patch by 
Jeff Garzik should be applied before applying this patch. There is 
more information and some ICH6R related patches at the project's home
page at http://iswraid.sourceforge.net/. The patch applies cleanly to
2.4.28-pre4 as well, and hopefully can be applied to any 2.4 kernel
without too much difficulty. 

The changes WRT version 0.1.4 are the following:
* Different buffer_head b_state bit used for IOs submitted
  to the mirror.
* Disk sizing problem for disks with odd number of sectors fixed.
* Entering degraded mode with many outstanding IOs fixed. 

Please consider this driver for inclusion in the 2.4 kernel tree.

Driver documentation is included in Documentation/iswraid.txt,
which is part of the patch. The license is GPL. I have added
myself to the MAINTAINERS list, please feel free to throw me
out if you don't think I should have done that.

Please let me know if there is anything else I can do to make
this driver acceptable for the 2.4 kernel.
 
   Martins Krikis
   Storage Components Division
   Intel Massachusetts



		

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Bartlomiej Zolnierkiewicz]

I may sound like an ignorant but...

Why can't device mapper be merged into 2.4 instead?
Is there something wrong with 2.4 device mapper patch?

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).

On Saturday 09 October 2004 22:44, Martins Krikis wrote:
> Version 0.1.4.3 of the Intel Sofware RAID driver (iswraid) is now
> available for the 2.4 series kernels at
> http://prdownloads.sourceforge.net/iswraid/2.4.28-pre3-iswraid.patch.gz?download
> 
> It is an ataraid "subdriver" but uses the SCSI subsystem to find the
> RAID member disks. It depends on the libata library, particularly the
> ata_piix driver that enables the Serial ATA capabilities in ICH5/ICH6
> chipsets. Hence, for kernels older than 2.4.28, the libata patch by 
> Jeff Garzik should be applied before applying this patch. There is 
> more information and some ICH6R related patches at the project's home
> page at http://iswraid.sourceforge.net/. The patch applies cleanly to
> 2.4.28-pre4 as well, and hopefully can be applied to any 2.4 kernel
> without too much difficulty. 
> 
> The changes WRT version 0.1.4 are the following:
> * Different buffer_head b_state bit used for IOs submitted
>   to the mirror.
> * Disk sizing problem for disks with odd number of sectors fixed.
> * Entering degraded mode with many outstanding IOs fixed. 
> 
> Please consider this driver for inclusion in the 2.4 kernel tree.
> 
> Driver documentation is included in Documentation/iswraid.txt,
> which is part of the patch. The license is GPL. I have added
> myself to the MAINTAINERS list, please feel free to throw me
> out if you don't think I should have done that.
> 
> Please let me know if there is anything else I can do to make
> this driver acceptable for the 2.4 kernel.
>  
>    Martins Krikis
>    Storage Components Division
>    Intel Massachusetts

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Jeff Garzik]

Bartlomiej Zolnierkiewicz wrote:
> I may sound like an ignorant but...
> 
> Why can't device mapper be merged into 2.4 instead?
> Is there something wrong with 2.4 device mapper patch?
> 
> 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).

OTOH, that would be introducing a brand new RAID/LVM subsystem in the 
middle of a stable series...

	Jeff

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Bartlomiej Zolnierkiewicz]

On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > I may sound like an ignorant but...
> >
> > Why can't device mapper be merged into 2.4 instead?
> > Is there something wrong with 2.4 device mapper patch?
> >
> > 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).
> 
> OTOH, that would be introducing a brand new RAID/LVM subsystem in the
> middle of a stable series...

Quoting Marcelo:

> New drivers are OK, as long as they dont break existing setups,
> and if substantial amount of users will benefit from it.

IMHO both conditions are fulfilled.

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Jeff Garzik]

Bartlomiej Zolnierkiewicz wrote:
> On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>Bartlomiej Zolnierkiewicz wrote:
>>
>>>I may sound like an ignorant but...
>>>
>>>Why can't device mapper be merged into 2.4 instead?
>>>Is there something wrong with 2.4 device mapper patch?
>>>
>>>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).
>>
>>OTOH, that would be introducing a brand new RAID/LVM subsystem in the
>>middle of a stable series...
> 
> 
> Quoting Marcelo:
> 
> 
>>New drivers are OK, as long as they dont break existing setups,
>>and if substantial amount of users will benefit from it.
> 
> 
> IMHO both conditions are fulfilled.


Note I said "subsystem", Marcelo said "driver".  I don't object to 
adding DM to 2.4.x, but I think it's a rather large addition with 
consequences WRT LVM1 versus LVM2, and perhaps other issues as well.

	Jeff

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Bartlomiej Zolnierkiewicz]

On Sat, 09 Oct 2004 19:36:13 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> 
> Bartlomiej Zolnierkiewicz wrote:
> > On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> >>Bartlomiej Zolnierkiewicz wrote:
> >>
> >>>I may sound like an ignorant but...
> >>>
> >>>Why can't device mapper be merged into 2.4 instead?
> >>>Is there something wrong with 2.4 device mapper patch?
> >>>
> >>>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).
> >>
> >>OTOH, that would be introducing a brand new RAID/LVM subsystem in the
> >>middle of a stable series...
> >
> >
> > Quoting Marcelo:
> >
> >
> >>New drivers are OK, as long as they dont break existing setups,
> >>and if substantial amount of users will benefit from it.
> >
> >
> > IMHO both conditions are fulfilled.
> 
> 
> Note I said "subsystem", Marcelo said "driver".  I don't object to
> adding DM to 2.4.x, but I think it's a rather large addition with
> consequences WRT LVM1 versus LVM2, and perhaps other issues as well.

I agree but merging iswraid into 2.4 can be compared to adding
new IDE host driver for SATA controller while libata is available.
I hope you get the idea. ;)

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Marcelo Tosatti]

On Sun, Oct 10, 2004 at 01:50:13AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Sat, 09 Oct 2004 19:36:13 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> > 
> > 
> > Bartlomiej Zolnierkiewicz wrote:
> > > On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> > >
> > >>Bartlomiej Zolnierkiewicz wrote:
> > >>
> > >>>I may sound like an ignorant but...
> > >>>
> > >>>Why can't device mapper be merged into 2.4 instead?
> > >>>Is there something wrong with 2.4 device mapper patch?
> > >>>
> > >>>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).
> > >>
> > >>OTOH, that would be introducing a brand new RAID/LVM subsystem in the
> > >>middle of a stable series...
> > >
> > >
> > > Quoting Marcelo:
> > >
> > >
> > >>New drivers are OK, as long as they dont break existing setups,
> > >>and if substantial amount of users will benefit from it.
> > >
> > >
> > > IMHO both conditions are fulfilled.
> > 
> > 
> > Note I said "subsystem", Marcelo said "driver".  I don't object to
> > adding DM to 2.4.x, but I think it's a rather large addition with
> > consequences WRT LVM1 versus LVM2, and perhaps other issues as well.
> 
> I agree but merging iswraid into 2.4 can be compared to adding
> new IDE host driver for SATA controller while libata is available.
> I hope you get the idea. ;)

Yeah but this is quite different.

We already have device mapper "like" functionality in v2.4 with RAID/LVM. 

I dont think that mergin device mapper is an option really, not in my opinion.

It seems the general consensus is to merge iswraid, so I'm fine with it.

Martins, we are approaching -rc stage, I would prefer the merge to happen 
at the beginning of 2.4.29-pre. Is that fine for you?

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Martins Krikis]

--- Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:

> It seems the general consensus is to merge iswraid, so I'm fine with
> it.
> 
> Martins, we are approaching -rc stage, I would prefer the merge to
> happen 
> at the beginning of 2.4.29-pre. Is that fine for you?

Yes, of course. It will give people more time to comment on it.
(I just don't want to miss the "2.4 train" completely.)

Thanks,

  Martins Krikis
  Storage Components Division
  Intel Massachusetts

 


		

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Martins Krikis]

--- 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.
 
> 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.
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.

> 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:
1) there might be something positive about the simple
usage of ataraid subdrivers,
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".

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.

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.
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



		

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Bartlomiej Zolnierkiewicz]

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

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Jeff Garzik]

Bartlomiej Zolnierkiewicz wrote:
> 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?


When the other RAIDs are ataraid in 2.4 and DM in 2.6, doing iswraid DM 
in 2.4 violates the Principle of Least Surprise ;-)

	Jeff

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Martins Krikis]

--- Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> 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?

Are you trying to say that "iswraid might look too good"
compared to what is currently available on 2.6 and therefore
should not be considered for inclusion in 2.4? A most interesting
reason indeed, I'm glad I said "fair" higher above, which it
certainly wouldn't be. Now, if such criteria were applied
against all new work, wouldn't that discourage new people
from contributing?

> > > 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.

Which is why it is the 2.6 kernel way. As for 2.4,
iswraid exists and I was planning to take responsibility
for it. Not that I'm a kernel expert, but I believe I
know what I was trying to put in iswraid.
 
> > 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

OK. I already replied above to that.

> > > 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)

Actually, that is not the reason. There is very little
dependence on ataraid in iswraid. It would be quite easy
to make iswraid a completely standalone driver. It has not 
been ported to 2.6 primarily because it would not be welcome
there, but I never expected any animosity towards it in 2.4. 

> > 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.

It still might and hopefully will, and I do believe that iswraid
has already helped advance Intel RAID metadata support in dmraid.
Heinz is the judge of that. More work was put into 2.4 because
those were the specific business requirements at the time.
Don't ask me more---I am just a coder and do not work for any
group that may be involved with ICH{5,6}.

  Martins Krikis
  Storage Components Division
  Intel Massachusetts



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Bartlomiej Zolnierkiewicz]

On Sat, 9 Oct 2004 18:00:51 -0700 (PDT), Martins Krikis
<mkrikis@yahoo.com> wrote:
> --- Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > 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?
> 
> Are you trying to say that "iswraid might look too good"
> compared to what is currently available on 2.6 and therefore
> should not be considered for inclusion in 2.4? A most interesting
> reason indeed, I'm glad I said "fair" higher above, which it

I said it before: iswraid in 2.4 is fine with.

> certainly wouldn't be. Now, if such criteria were applied
> against all new work, wouldn't that discourage new people
> from contributing?

We SHOULD be discouraging new people from
contributing to DEPRECATED kernel series.

You can treat my complaints as "2.4 kernel tax". :-)

> > > > 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.
> 
> Which is why it is the 2.6 kernel way. As for 2.4,
> iswraid exists and I was planning to take responsibility
> for it. Not that I'm a kernel expert, but I believe I
> know what I was trying to put in iswraid.

I don't question that.

> > > 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)
> 
> Actually, that is not the reason. There is very little
> dependence on ataraid in iswraid. It would be quite easy
> to make iswraid a completely standalone driver. It has not
> been ported to 2.6 primarily because it would not be welcome

not because user-space solution is superior?

> there, but I never expected any animosity towards it in 2.4.

I'm sorry that I dare to not love iswraid... ;-)

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Martins Krikis]

--- Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> We SHOULD be discouraging new people from
> contributing to DEPRECATED kernel series.

But 2.4 wasn't quite that deprecated when version 0.0.6
of iswraid was announced on Nov 24, 2003. I don't know
the exact 2.6 timeline but ChangeLog-2.6.0 at www.kernel.org
seems to be dated Dec 17, 2003. Yes, perhaps we should
have asked for consideration sooner...

> > Actually, that is not the reason. There is very little
> > dependence on ataraid in iswraid. It would be quite easy
> > to make iswraid a completely standalone driver. It has not
> > been ported to 2.6 primarily because it would not be welcome
> 
> not because user-space solution is superior?

Like you said, superior from a maintenance point of view.
The users might choose a different measure for superiority.
The coder doing the work may choose yet another way of
deciding which way to proceed. For example, if time was all
that mattered, I think, it would be faster for me to just make
an iswraid port to 2.6 than to try to work with dm+dmraid
which I know very little about, in order to get the same
features supported. But, because I can't speak for my employer,
let me agree with you here and say that yes, I stand corrected,
it is quite possible that it has not been ported because a user
space solution is superior.

> I'm sorry that I dare to not love iswraid... ;-)

You've made your reasons so clear that I don't really mind.

   These opinions are solely mine and
   may not agree with those of my employer.

   Martins Krikis



		

Re: [Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3

[Alan Cox]

On Sad, 2004-10-09 at 21:44, Martins Krikis wrote:
> It is an ataraid "subdriver" but uses the SCSI subsystem to find the
> RAID member disks. It depends on the libata library, particularly the
> ata_piix driver that enables the Serial ATA capabilities in ICH5/ICH6
> chipsets. Hence, for kernels older than 2.4.28, the libata patch by 
> Jeff Garzik should be applied before applying this patch.

This seems to make sense to me - for 2.6 we have the DM layer, for 2.4
we've used the ataraid stuff.