Version 0.1.5 of the Intel Sofware RAID driver (iswraid) is now
available for the 2.4 series kernels at
http://prdownloads.sourceforge.net/iswraid/2.4.29-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 on
either the ata_piix or the ahci driver, that enable the Serial ATA
capabilities in ICH5/ICH6/ICH7 chipsets. More information is available
at the project's home page at http://iswraid.sourceforge.net/.
Driver documentation is included in Documentation/iswraid.txt,
which is part of the patch. The license is GPL.
The changes WRT version 0.1.4.3 are the following:
* Resource deallocation bug fixed for failed initializations.
* Read IO resubmission to mirror bug fixed.
* RAID1E (covers 4-disk RAID10) code added.
* More aggressive marking disks as bad in metadata.
* Claiming disks for RAID "feature" removed.
* Option defaults now customizable from the build configuration.
* iswraid_never_fail "feature" watered down into iswraid_resist_failing.
* iswraid_halt_degraded now prevents degraded volumes from being registered.
* Debug printouts more customizable.
* Some code cleanup and optimization.
* Documentation changes.
Please consider this driver for inclusion in the 2.4 kernel tree.
Martins Krikis
Storage Components Division
Intel Massachusetts
P.S. I've CC-d directly to the potential reviewers suggested a few months ago
by Marcelo. I'll appreciate any feedback you (and others) can provide.
Martins Krikis wrote:
> Version 0.1.5 of the Intel Sofware RAID driver (iswraid) is now
> available for the 2.4 series kernels at
> http://prdownloads.sourceforge.net/iswraid/2.4.29-iswraid.patch.gz?download
ACK from me
On Sat, 2005-02-05 at 21:36 -0500, Jeff Garzik wrote:
> Martins Krikis wrote:
> > Version 0.1.5 of the Intel Sofware RAID driver (iswraid) is now
> > available for the 2.4 series kernels at
> > http://prdownloads.sourceforge.net/iswraid/2.4.29-iswraid.patch.gz?download
>
> ACK from me
personally I consider it a new feature, and I don't consider new
features like this appropriate for a 2.4 deep maintenance stream.
On Sun, 06 Feb 2005 10:27:56 +0100, Arjan van de Ven
<[email protected]> wrote:
> On Sat, 2005-02-05 at 21:36 -0500, Jeff Garzik wrote:
> > Martins Krikis wrote:
> > > Version 0.1.5 of the Intel Sofware RAID driver (iswraid) is now
> > > available for the 2.4 series kernels at
> > > http://prdownloads.sourceforge.net/iswraid/2.4.29-iswraid.patch.gz?download
> >
> > ACK from me
>
> personally I consider it a new feature, and I don't consider new
> features like this appropriate for a 2.4 deep maintenance stream.
I have the same opinion
Bartlomiej Zolnierkiewicz wrote:
> On Sun, 06 Feb 2005 10:27:56 +0100, Arjan van de Ven
> <[email protected]> wrote:
>
>>On Sat, 2005-02-05 at 21:36 -0500, Jeff Garzik wrote:
>>
>>>Martins Krikis wrote:
>>>
>>>>Version 0.1.5 of the Intel Sofware RAID driver (iswraid) is now
>>>>available for the 2.4 series kernels at
>>>>http://prdownloads.sourceforge.net/iswraid/2.4.29-iswraid.patch.gz?download
>>>
>>>ACK from me
>>
>> personally I consider it a new feature, and I don't consider new
>>features like this appropriate for a 2.4 deep maintenance stream.
>
>
> I have the same opinion
It sorts sucks for users with that hardware. The typical complaint
comes from trying to share data between Windows and Linux, where "just
use md" isn't a solution.
Without device mapper (another new feature) to enable dmraid, these
users are just sorta S.O.L.
I consider it not a new feature, but a missing feature, since otherwise
user data cannot be accessed in the RAID setups.
Jeff
On Sun, Feb 06, 2005 at 09:38:54AM -0500, Jeff Garzik wrote:
> Without device mapper (another new feature) to enable dmraid, these
> users are just sorta S.O.L.
>
> I consider it not a new feature, but a missing feature, since otherwise
> user data cannot be accessed in the RAID setups.
So those people should switch to Linux 2.6, or simply avoid using one
of the various softraid variants for the data they want to share with
windows. Both Linux (md or dm) and Windows (LDM) can mirror individual
partitions just fine.
> I consider it not a new feature, but a missing feature, since otherwise
> user data cannot be accessed in the RAID setups.
the same is true for all new hardware drivers and hardware support
patches. And for new DRM (since new X may need it) and new .. and
new ... where is the line?
for me a deep maintenance mode is about keeping existing stuff working;
all new hw support and derivative hardware support (such as this) can be
pointed at the new stable series... which has been out for quite some
time now..
Arjan van de Ven wrote:
>>I consider it not a new feature, but a missing feature, since otherwise
>>user data cannot be accessed in the RAID setups.
>
>
> the same is true for all new hardware drivers and hardware support
> patches. And for new DRM (since new X may need it) and new .. and
> new ... where is the line?
>
> for me a deep maintenance mode is about keeping existing stuff working;
> all new hw support and derivative hardware support (such as this) can be
> pointed at the new stable series... which has been out for quite some
> time now..
Red herring.
2.4.x has ICH5/6 support -- but is missing the RAID support component.
We are talking about hardware that is ALREADY supported by 2.4.x kernel,
not new hardware.
We are also talking about inability to access data on hardware supported
by 2.4.x, not something that can easily be ignored or papered over with
a compatibility mode.
Jeff
On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[email protected]> wrote:
> Arjan van de Ven wrote:
> >>I consider it not a new feature, but a missing feature, since otherwise
> >>user data cannot be accessed in the RAID setups.
> >
> >
> > the same is true for all new hardware drivers and hardware support
> > patches. And for new DRM (since new X may need it) and new .. and
> > new ... where is the line?
> >
> > for me a deep maintenance mode is about keeping existing stuff working;
> > all new hw support and derivative hardware support (such as this) can be
> > pointed at the new stable series... which has been out for quite some
> > time now..
>
> Red herring.
>
> 2.4.x has ICH5/6 support -- but is missing the RAID support component.
>
> We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> not new hardware.
>
> We are also talking about inability to access data on hardware supported
> by 2.4.x, not something that can easily be ignored or papered over with
> a compatibility mode.
the same arguments can be used for crypto support etc.,
answer is - use 2.6.x or add extra patches to get 2.4.x working
On Sun, 2005-02-06 at 10:03 -0500, Jeff Garzik wrote:
> Arjan van de Ven wrote:
> >>I consider it not a new feature, but a missing feature, since otherwise
> >>user data cannot be accessed in the RAID setups.
> >
> >
> > the same is true for all new hardware drivers and hardware support
> > patches. And for new DRM (since new X may need it) and new .. and
> > new ... where is the line?
> >
> > for me a deep maintenance mode is about keeping existing stuff working;
> > all new hw support and derivative hardware support (such as this) can be
> > pointed at the new stable series... which has been out for quite some
> > time now..
>
> Red herring.
>
> 2.4.x has ICH5/6 support -- but is missing the RAID support component.
>
> We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> not new hardware.
I'm talking about derivative hardware support. While this is not
technically a hardware device driver, it sure is similar to one.
> We are also talking about inability to access data on hardware supported
> by 2.4.x, not something that can easily be ignored or papered over with
> a compatibility mode.
It's a new feature. It's support for a hw related feature not previously
supported. Now you can argue if such a new feature is appropriate or
not, but I don't see any way of arguing that this is not a new feature.
On Sun, Feb 06, 2005 at 10:03:27AM -0500, Jeff Garzik wrote:
> Red herring.
>
> 2.4.x has ICH5/6 support -- but is missing the RAID support component.
>
> We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> not new hardware.
You're talking about software not support (the intel bios fakeraid format).
Christoph Hellwig wrote:
> On Sun, Feb 06, 2005 at 10:03:27AM -0500, Jeff Garzik wrote:
>
>>Red herring.
>>
>>2.4.x has ICH5/6 support -- but is missing the RAID support component.
>>
>>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
>>not new hardware.
>
>
> You're talking about software not support (the intel bios fakeraid format).
I'm talking about being able to access data, or not.
Jeff
On Sun, Feb 06, 2005 at 11:09:37AM -0500, Jeff Garzik wrote:
> I'm talking about being able to access data, or not.
And your point is?
--- Arjan van de Ven <[email protected]> wrote:
>
> > I consider it not a new feature, but a missing feature, since
> otherwise
> > user data cannot be accessed in the RAID setups.
>
> the same is true for all new hardware drivers and hardware support
> patches. And for new DRM (since new X may need it) and new .. and
> new ... where is the line?
>
> for me a deep maintenance mode is about keeping existing stuff
> working;
> all new hw support and derivative hardware support (such as this) can
> be
> pointed at the new stable series... which has been out for quite some
> time now..
Would it help my case if I swore that iswraid has been released
for longer than the "new stable series" and that it is in "deep
maintenance mode" itself, just outside the 2.4 kernel tree?
(Version 0.0.6 (for 2.4.22) was announced Nov. 24, 2003.)
I do realize that Intel should have asked a long time ago for it
to be considered for acceptance (I did ask back in October for
2.4.28). But there are positive aspects to accepting a driver
late---there is a much higher chance that all the issues have
been solved. (If there are any particular worries about the
newly added RAID1E code, well, it's only useful for ICH7R, I'd
be almost as happy if an older version without it got accepted.)
To conclude, Marcelo's words back in October 9 were:
"New drivers are OK, as long as they don't break existing setups,
and if substantial amount of users will benefit from it."
So here is a "new driver" (that's been around for a while)
which I don't think can break anything. As to the "substantial
amount of users", the two SourceForge releases with download
statistics have each seen about 800 downloads, I have no idea
whether that counts as substantial.
Martins Krikis
Storage Components Division
Intel Massachusetts
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Martins Krikis <[email protected]> writes:
> I do realize that Intel should have asked a long time ago for it
> to be considered for acceptance (I did ask back in October for
> 2.4.28).
Sorry about all the noise, but I just remembered some other important
aspects that played a role here.
Intel couldn't really ask for the inclusion of iswraid into the tree
much earlier than October because iswraid depends on either ata_piix
or ahci, both part of libata. Libata was included in 2.4.27, ata_piix
in 2.4.28, ahci in 2.4.29.
So I first asked for iswraid to be considered during 2.4.28-pre3 stage.
I was told that it's almost being released and that I should wait
for 2.4.29. There was also a discussion about whether it even belongs
or whether dm belongs more. With 2.4.29 I forgot to remind everybody
to look at iswraid and when I did it was too late for 2.4.29 and
Marcelo asked Jeff to review it for 2.4.30-pre1. (And thanks for
your support, Jeff.)
In short, I only first asked for it to be included with 2.4.28, but
I could not have done it earlier than that anyway because drivers it
depends on weren't yet in 2.4.
Martins Krikis
Storage Components Division
Intel Massachusetts
On Sun, Feb 06, 2005 at 03:49:33PM +0100, Arjan van de Ven wrote:
>
> > I consider it not a new feature, but a missing feature, since otherwise
> > user data cannot be accessed in the RAID setups.
>
> the same is true for all new hardware drivers and hardware support
> patches. And for new DRM (since new X may need it) and new .. and
> new ... where is the line?
>
> for me a deep maintenance mode is about keeping existing stuff working;
> all new hw support and derivative hardware support (such as this) can be
> pointed at the new stable series... which has been out for quite some
> time now..
I personally dislike and discourage the addition of ANY new drivers to v2.4 at
this point, and I sincerely appreciate every argument against iswraid, but I
have no problems with it because it looks like a valid special case since it
allows users to access their ICH5/6 RAID partitions, as Jeff mentions.
Moreover the driver is going to die with v2.4 anyway, its not like any future
compatibility problem is being introduced.
So I understand the argument against having it in the tree: the elegant way of doing
it is to use dmraid.
But I dont buy it as an argument against merging it in a dying v2.4.x tree which
purpose is to serve existing users.
You are mistaken in arguing that "oh, since this driver can be merged, its likely that
any v2.6 HW support/driver will be accepted in v2.4".
So, its up to Jeff, and he seems to be OK with it.
Bartlomiej Zolnierkiewicz wrote:
> On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[email protected]> wrote:
>
>>Arjan van de Ven wrote:
>>
>>>>I consider it not a new feature, but a missing feature, since otherwise
>>>>user data cannot be accessed in the RAID setups.
>>>
>>>
>>>the same is true for all new hardware drivers and hardware support
>>>patches. And for new DRM (since new X may need it) and new .. and
>>>new ... where is the line?
>>>
>>>for me a deep maintenance mode is about keeping existing stuff working;
>>>all new hw support and derivative hardware support (such as this) can be
>>>pointed at the new stable series... which has been out for quite some
>>>time now..
>>
>>Red herring.
>>
>>2.4.x has ICH5/6 support -- but is missing the RAID support component.
>>
>>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
>>not new hardware.
>>
>>We are also talking about inability to access data on hardware supported
>>by 2.4.x, not something that can easily be ignored or papered over with
>>a compatibility mode.
>
>
> the same arguments can be used for crypto support etc.,
> answer is - use 2.6.x or add extra patches to get 2.4.x working
It's fix in a sense. The hardware is supported now, just not very well.
If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
it would be a fix, in this case thehardware is supported partially, the
RAID conponent isn't working, and this is the fix.
It is stretching a point, but adding support for all the features of
hardware which is currently supported just seems to be a valud operation
to me. New crypto feels more like adding a whole new device.
Opinion offered for clarification only, I don't feel strongly on this or
crypto, but I do identify because I have hardware with a 2.4 driver and
I can't use it unless I give up 2.6.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[email protected]> wrote:
> >
> >>Arjan van de Ven wrote:
> >>
> >>>>I consider it not a new feature, but a missing feature, since otherwise
> >>>>user data cannot be accessed in the RAID setups.
> >>>
> >>>
> >>>the same is true for all new hardware drivers and hardware support
> >>>patches. And for new DRM (since new X may need it) and new .. and
> >>>new ... where is the line?
> >>>
> >>>for me a deep maintenance mode is about keeping existing stuff working;
> >>>all new hw support and derivative hardware support (such as this) can be
> >>>pointed at the new stable series... which has been out for quite some
> >>>time now..
> >>
> >>Red herring.
> >>
> >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> >>
> >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> >>not new hardware.
> >>
> >>We are also talking about inability to access data on hardware supported
> >>by 2.4.x, not something that can easily be ignored or papered over with
> >>a compatibility mode.
> >
> >
> > the same arguments can be used for crypto support etc.,
> > answer is - use 2.6.x or add extra patches to get 2.4.x working
>
> It's fix in a sense. The hardware is supported now, just not very well.
> If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> it would be a fix, in this case thehardware is supported partially, the
> RAID conponent isn't working, and this is the fix.
The so called "RAID component" is 100% *software* solution.
BTW What is UDA?
On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[email protected]> wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[email protected]> wrote:
> > >
> > >>Arjan van de Ven wrote:
> > >>
> > >>>>I consider it not a new feature, but a missing feature, since otherwise
> > >>>>user data cannot be accessed in the RAID setups.
> > >>>
> > >>>
> > >>>the same is true for all new hardware drivers and hardware support
> > >>>patches. And for new DRM (since new X may need it) and new .. and
> > >>>new ... where is the line?
> > >>>
> > >>>for me a deep maintenance mode is about keeping existing stuff working;
> > >>>all new hw support and derivative hardware support (such as this) can be
> > >>>pointed at the new stable series... which has been out for quite some
> > >>>time now..
> > >>
> > >>Red herring.
> > >>
> > >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> > >>
> > >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> > >>not new hardware.
> > >>
> > >>We are also talking about inability to access data on hardware supported
> > >>by 2.4.x, not something that can easily be ignored or papered over with
> > >>a compatibility mode.
> > >
> > >
> > > the same arguments can be used for crypto support etc.,
> > > answer is - use 2.6.x or add extra patches to get 2.4.x working
> >
> > It's fix in a sense. The hardware is supported now, just not very well.
> > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> > it would be a fix, in this case thehardware is supported partially, the
> > RAID conponent isn't working, and this is the fix.
>
> The so called "RAID component" is 100% *software* solution.
>
> BTW What is UDA?
[ This mail is just to explain why I don't like iswraid,
I don't care if it gets merged that much... ]
another BTW: this driver adds another incompatibility between
2.4.x and 2.6.x. Also most 2.4.x users will want (or have to) migrate
to 2.6.x one day and they will have to switch to using device mapper
and dmraid anyway. From my POV merging/supporting iswraid
in any way is a lost of time for EVERYBODY in the long-term.
Martins, I appreciate all hard work that went into iswraid driver but
please face the simple fact, this driver was already obsoleted in
the moment it was created (from Linux development process POV).
I previously (October?) asked about merging device-mapper
instead as it provides easier way to migrate to 2.6.x (not only for
Intel "RAID component" users but for ALL "RAID components" users)
as they would be able to use the same method for accessing their
data in both kernels. I was said that it is too late for such changes
(I consider device-mapper a new driver, changes to existing code
are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
2.6.x to device-mapper which was just silly argument IMHO (why we
don't stick to IDE drivers for SATA in 2.4.x?). I finally gave up because
I didn't want to waste more my time on this and didn't want to go into
politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)
Regards,
Bartlomiej
On Thu, Feb 10, 2005 at 11:04:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> > On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[email protected]> wrote:
> > > Bartlomiej Zolnierkiewicz wrote:
> > > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[email protected]> wrote:
> > > >
> > > >>Arjan van de Ven wrote:
> > > >>
> > > >>>>I consider it not a new feature, but a missing feature, since otherwise
> > > >>>>user data cannot be accessed in the RAID setups.
> > > >>>
> > > >>>
> > > >>>the same is true for all new hardware drivers and hardware support
> > > >>>patches. And for new DRM (since new X may need it) and new .. and
> > > >>>new ... where is the line?
> > > >>>
> > > >>>for me a deep maintenance mode is about keeping existing stuff working;
> > > >>>all new hw support and derivative hardware support (such as this) can be
> > > >>>pointed at the new stable series... which has been out for quite some
> > > >>>time now..
> > > >>
> > > >>Red herring.
> > > >>
> > > >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> > > >>
> > > >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> > > >>not new hardware.
> > > >>
> > > >>We are also talking about inability to access data on hardware supported
> > > >>by 2.4.x, not something that can easily be ignored or papered over with
> > > >>a compatibility mode.
> > > >
> > > >
> > > > the same arguments can be used for crypto support etc.,
> > > > answer is - use 2.6.x or add extra patches to get 2.4.x working
> > >
> > > It's fix in a sense. The hardware is supported now, just not very well.
> > > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> > > it would be a fix, in this case thehardware is supported partially, the
> > > RAID conponent isn't working, and this is the fix.
> >
> > The so called "RAID component" is 100% *software* solution.
> >
> > BTW What is UDA?
>
> [ This mail is just to explain why I don't like iswraid,
> I don't care if it gets merged that much... ]
>
> another BTW: this driver adds another incompatibility between
> 2.4.x and 2.6.x.
What do you mean "adds another incompatibility" ?
That users will have to switch to dmraid when upgrading to v2.6.x ?
> Also most 2.4.x users will want (or have to) migrate
> to 2.6.x one day and they will have to switch to using device mapper
> and dmraid anyway. From my POV merging/supporting iswraid
> in any way is a lost of time for EVERYBODY in the long-term.
> Martins, I appreciate all hard work that went into iswraid driver but
> please face the simple fact, this driver was already obsoleted in
> the moment it was created (from Linux development process POV).
>
> I previously (October?) asked about merging device-mapper
> instead as it provides easier way to migrate to 2.6.x (not only for
> Intel "RAID component" users but for ALL "RAID components" users)
> as they would be able to use the same method for accessing their
> data in both kernels. I was said that it is too late for such changes
> (I consider device-mapper a new driver, changes to existing code
> are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
> 2.6.x to device-mapper which was just silly argument IMHO (why we
> don't stick to IDE drivers for SATA in 2.4.x?).
SATA is not the same case as sw-RAID in my POV Bart, it allows many
users to be _able_ use SATA controllers/drives.
> I finally gave up because I didn't want to waste more my time on this and
> didn't want to go into
> politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)
Good to hear your opinion.
On Thu, 10 Feb 2005 16:39:34 -0200, Marcelo Tosatti
<[email protected]> wrote:
> On Thu, Feb 10, 2005 at 11:04:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz
> > <[email protected]> wrote:
> > > On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[email protected]> wrote:
> > > > Bartlomiej Zolnierkiewicz wrote:
> > > > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[email protected]> wrote:
> > > > >
> > > > >>Arjan van de Ven wrote:
> > > > >>
> > > > >>>>I consider it not a new feature, but a missing feature, since otherwise
> > > > >>>>user data cannot be accessed in the RAID setups.
> > > > >>>
> > > > >>>
> > > > >>>the same is true for all new hardware drivers and hardware support
> > > > >>>patches. And for new DRM (since new X may need it) and new .. and
> > > > >>>new ... where is the line?
> > > > >>>
> > > > >>>for me a deep maintenance mode is about keeping existing stuff working;
> > > > >>>all new hw support and derivative hardware support (such as this) can be
> > > > >>>pointed at the new stable series... which has been out for quite some
> > > > >>>time now..
> > > > >>
> > > > >>Red herring.
> > > > >>
> > > > >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> > > > >>
> > > > >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> > > > >>not new hardware.
> > > > >>
> > > > >>We are also talking about inability to access data on hardware supported
> > > > >>by 2.4.x, not something that can easily be ignored or papered over with
> > > > >>a compatibility mode.
> > > > >
> > > > >
> > > > > the same arguments can be used for crypto support etc.,
> > > > > answer is - use 2.6.x or add extra patches to get 2.4.x working
> > > >
> > > > It's fix in a sense. The hardware is supported now, just not very well.
> > > > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> > > > it would be a fix, in this case thehardware is supported partially, the
> > > > RAID conponent isn't working, and this is the fix.
> > >
> > > The so called "RAID component" is 100% *software* solution.
> > >
> > > BTW What is UDA?
> >
> > [ This mail is just to explain why I don't like iswraid,
> > I don't care if it gets merged that much... ]
> >
> > another BTW: this driver adds another incompatibility between
> > 2.4.x and 2.6.x.
>
> What do you mean "adds another incompatibility" ?
>
> That users will have to switch to dmraid when upgrading to v2.6.x ?
It is worse than that - AFAIR iswraid provides some features which
are NOT available in 2.6.x kernels.
> > Also most 2.4.x users will want (or have to) migrate
> > to 2.6.x one day and they will have to switch to using device mapper
> > and dmraid anyway. From my POV merging/supporting iswraid
> > in any way is a lost of time for EVERYBODY in the long-term.
> > Martins, I appreciate all hard work that went into iswraid driver but
> > please face the simple fact, this driver was already obsoleted in
> > the moment it was created (from Linux development process POV).
> >
> > I previously (October?) asked about merging device-mapper
> > instead as it provides easier way to migrate to 2.6.x (not only for
> > Intel "RAID component" users but for ALL "RAID components" users)
> > as they would be able to use the same method for accessing their
> > data in both kernels. I was said that it is too late for such changes
> > (I consider device-mapper a new driver, changes to existing code
> > are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
> > 2.6.x to device-mapper which was just silly argument IMHO (why we
> > don't stick to IDE drivers for SATA in 2.4.x?).
>
> SATA is not the same case as sw-RAID in my POV Bart, it allows many
> users to be _able_ use SATA controllers/drives.
Fully agreed but what is your point? Mine was that we can different
subsystems/drivers for the same device/functionality - like we have
both IDE+siimage and libata+sata_sil drivers in 2.4.x.
Maybe Martins was forced to develop for ataraid in 2.4.x
because lack of device-mapper. In such case the current
situations is our fault and we can learn something from it.
> > I finally gave up because I didn't want to waste more my time on this and
> > didn't want to go into
> > politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)
>
> Good to hear your opinion.
Hi Bart,
On Fri, Feb 11, 2005 at 12:28:04AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > [ This mail is just to explain why I don't like iswraid,
> > > I don't care if it gets merged that much... ]
> > >
> > > another BTW: this driver adds another incompatibility between
> > > 2.4.x and 2.6.x.
> >
> > What do you mean "adds another incompatibility" ?
> >
> > That users will have to switch to dmraid when upgrading to v2.6.x ?
>
> It is worse than that - AFAIR iswraid provides some features which
> are NOT available in 2.6.x kernels.
Oh really?
> > > Also most 2.4.x users will want (or have to) migrate
> > > to 2.6.x one day and they will have to switch to using device mapper
> > > and dmraid anyway. From my POV merging/supporting iswraid
> > > in any way is a lost of time for EVERYBODY in the long-term.
> > > Martins, I appreciate all hard work that went into iswraid driver but
> > > please face the simple fact, this driver was already obsoleted in
> > > the moment it was created (from Linux development process POV).
> > >
> > > I previously (October?) asked about merging device-mapper
> > > instead as it provides easier way to migrate to 2.6.x (not only for
> > > Intel "RAID component" users but for ALL "RAID components" users)
> > > as they would be able to use the same method for accessing their
> > > data in both kernels. I was said that it is too late for such changes
> > > (I consider device-mapper a new driver, changes to existing code
> > > are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
> > > 2.6.x to device-mapper which was just silly argument IMHO (why we
> > > don't stick to IDE drivers for SATA in 2.4.x?).
> >
> > SATA is not the same case as sw-RAID in my POV Bart, it allows many
> > users to be _able_ use SATA controllers/drives.
>
> Fully agreed but what is your point? Mine was that we can different
> subsystems/drivers for the same device/functionality - like we have
> both IDE+siimage and libata+sata_sil drivers in 2.4.x.
My point is that the SATA subsystem is a very different case from
device-mapper.
The SATA subsystem provides _hardware_ knowledge, it provides the ability
for certain very popular devices to work, and improved functionality
for devices which could be driven by the IDE subsystem.
Now the device mapper can be thought of as a high-level abstraction in which
LVM, RAID, and other functionality can be built on top of. We already have
those in v2.4.
They are quite different.
> Maybe Martins was forced to develop for ataraid in 2.4.x
> because lack of device-mapper. In such case the current
> situations is our fault and we can learn something from it.
True.
> > > I finally gave up because I didn't want to waste more my time on this and
> > > didn't want to go into
> > > politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)
> >
> > Good to hear your opinion.
On Thu, 2005-02-10 at 16:39 -0200, Marcelo Tosatti wrote:
> What do you mean "adds another incompatibility" ?
>
> That users will have to switch to dmraid when upgrading to v2.6.x ?
which is a rather disruptive and incompatible change. device names
change etc etc.
> SATA is not the same case as sw-RAID in my POV Bart, it allows many
> users to be _able_ use SATA controllers/drives.
without sata in the kernel, those were still driven by the legacy ide
driver, just not as fast/optimal.