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
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
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
--- Bartlomiej Zolnierkiewicz <[email protected]> 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
On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <[email protected]> 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.
Bartlomiej Zolnierkiewicz wrote:
> On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <[email protected]> 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
On Sat, 9 Oct 2004 16:03:00 -0700 (PDT), Martins Krikis
<[email protected]> wrote:
> --- Bartlomiej Zolnierkiewicz <[email protected]> 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
On Sat, 09 Oct 2004 19:36:13 -0400, Jeff Garzik <[email protected]> wrote:
>
>
> Bartlomiej Zolnierkiewicz wrote:
> > On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <[email protected]> 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. ;)
Bartlomiej Zolnierkiewicz wrote:
> On Sat, 9 Oct 2004 16:03:00 -0700 (PDT), Martins Krikis
> <[email protected]> wrote:
>
>>--- Bartlomiej Zolnierkiewicz <[email protected]> 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
--- Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Sat, 9 Oct 2004 16:03:00 -0700 (PDT), Martins Krikis
> <[email protected]> wrote:
> > --- Bartlomiej Zolnierkiewicz <[email protected]> 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
On Sat, 9 Oct 2004 18:00:51 -0700 (PDT), Martins Krikis
<[email protected]> wrote:
> --- Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > On Sat, 9 Oct 2004 16:03:00 -0700 (PDT), Martins Krikis
> > <[email protected]> wrote:
> > > --- Bartlomiej Zolnierkiewicz <[email protected]> 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... ;-)
--- Martins Krikis <[email protected]> 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
--- Bartlomiej Zolnierkiewicz <[email protected]> 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 http://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
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.
On Sun, Oct 10, 2004 at 01:50:13AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Sat, 09 Oct 2004 19:36:13 -0400, Jeff Garzik <[email protected]> wrote:
> >
> >
> > Bartlomiej Zolnierkiewicz wrote:
> > > On Sat, 09 Oct 2004 18:07:29 -0400, Jeff Garzik <[email protected]> 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?
--- Marcelo Tosatti <[email protected]> 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
--- Marcelo Tosatti <[email protected]> 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?
Marcelo,
I seemed to have missed the 2.4.29-pre stages, unfortunately.
Are you planning on a 2.4.30, too? I'd still love to get
iswraid accepted in the 2.4 tree eventually...
The version that's out on SourceForge right now would be alright
as is with the 2.4.29-x kernels, if that's any help. In about a
week I'm planning to have a new version that adds RAID10 support
for the ICH7R-based machines. Please let me know what my options
are (if any) regarding getting iswraid in 2.4.
Thanks very much,
Martins Krikis
Storage Components Division
Intel Massachusetts
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Martins Krikis wrote:
> --- Marcelo Tosatti <[email protected]> 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?
>
>
> Marcelo,
>
> I seemed to have missed the 2.4.29-pre stages, unfortunately.
> Are you planning on a 2.4.30, too? I'd still love to get
> iswraid accepted in the 2.4 tree eventually...
>
> The version that's out on SourceForge right now would be alright
> as is with the 2.4.29-x kernels, if that's any help. In about a
> week I'm planning to have a new version that adds RAID10 support
> for the ICH7R-based machines. Please let me know what my options
> are (if any) regarding getting iswraid in 2.4.
I ACK getting this into 2.4, as well...
Jeff
On Tue, Jan 18, 2005 at 09:28:16AM -0800, Martins Krikis wrote:
> --- Marcelo Tosatti <[email protected]> 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?
>
> Marcelo,
>
> I seemed to have missed the 2.4.29-pre stages, unfortunately.
> Are you planning on a 2.4.30, too? I'd still love to get
> iswraid accepted in the 2.4 tree eventually...
>
> The version that's out on SourceForge right now would be alright
> as is with the 2.4.29-x kernels, if that's any help. In about a
> week I'm planning to have a new version that adds RAID10 support
> for the ICH7R-based machines. Please let me know what my options
> are (if any) regarding getting iswraid in 2.4.
Hi Martins,
My feeling at the moment is to avoid any merges if possible - only
critical stuff for v2.4.
> Thanks very much,
Sorry!
On Tue, Jan 18, 2005 at 01:13:23PM -0500, Jeff Garzik wrote:
> Martins Krikis wrote:
> >--- Marcelo Tosatti <[email protected]> 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?
> >
> >
> >Marcelo,
> >
> >I seemed to have missed the 2.4.29-pre stages, unfortunately.
> >Are you planning on a 2.4.30, too? I'd still love to get
> >iswraid accepted in the 2.4 tree eventually...
> >
> >The version that's out on SourceForge right now would be alright
> >as is with the 2.4.29-x kernels, if that's any help. In about a
> >week I'm planning to have a new version that adds RAID10 support
> >for the ICH7R-based machines. Please let me know what my options
> >are (if any) regarding getting iswraid in 2.4.
>
> I ACK getting this into 2.4, as well...
OK, can you please review if for 2.4.30-pre Jeff ?
Marcelo Tosatti wrote:
> On Tue, Jan 18, 2005 at 01:13:23PM -0500, Jeff Garzik wrote:
>
>>Martins Krikis wrote:
>>
>>>--- Marcelo Tosatti <[email protected]> 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?
>>>
>>>
>>>Marcelo,
>>>
>>>I seemed to have missed the 2.4.29-pre stages, unfortunately.
>>>Are you planning on a 2.4.30, too? I'd still love to get
>>>iswraid accepted in the 2.4 tree eventually...
>>>
>>>The version that's out on SourceForge right now would be alright
>>>as is with the 2.4.29-x kernels, if that's any help. In about a
>>>week I'm planning to have a new version that adds RAID10 support
>>>for the ICH7R-based machines. Please let me know what my options
>>>are (if any) regarding getting iswraid in 2.4.
>>
>>I ACK getting this into 2.4, as well...
>
>
> OK, can you please review if for 2.4.30-pre Jeff ?
Check your inbox from months ago ;-) AFAICS his current version
addresses all the comments from Alan and myself, from when it hit lkml 6
months(?) ago...
I'll give it another quick lookover though, sure.
Jeff
--- Jeff Garzik <[email protected]> wrote:
> Check your inbox from months ago ;-) AFAICS his current version
> addresses all the comments from Alan and myself, from when it hit
> lkml 6
> months(?) ago...
>
> I'll give it another quick lookover though, sure.
Jeff,
As long as 2.4.30 is planned at all, I have no more
worries for the moment. But if so, then please don't
waste your time looking over the current version. In
about a week there should really be another one out.
It will add RAID10, and get rid of the "claim disks
for RAID" mis-feature. I'll let everybody know, of course.
Thanks,
Martins Krikis
Storage Components Division
Intel Massachusetts
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
Hi,
On Tue, 18 Jan 2005 11:56:21 -0800 (PST), Martins Krikis
<[email protected]> wrote:
> --- Jeff Garzik <[email protected]> wrote:
>
> > Check your inbox from months ago ;-) AFAICS his current version
> > addresses all the comments from Alan and myself, from when it hit
> > lkml 6
> > months(?) ago...
> >
> > I'll give it another quick lookover though, sure.
>
> Jeff,
>
> As long as 2.4.30 is planned at all, I have no more
> worries for the moment. But if so, then please don't
> waste your time looking over the current version. In
> about a week there should really be another one out.
> It will add RAID10, and get rid of the "claim disks
> for RAID" mis-feature. I'll let everybody know, of course.
I'm just curious. Is there already a possibility to use
RAID10 metadata in 2.6.x kernels?
Thanks,
Bartlomiej
Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Tue, 18 Jan 2005 11:56:21 -0800 (PST), Martins Krikis
> <[email protected]> wrote:
>
>>--- Jeff Garzik <[email protected]> wrote:
>>
>>
>>>Check your inbox from months ago ;-) AFAICS his current version
>>>addresses all the comments from Alan and myself, from when it hit
>>>lkml 6
>>>months(?) ago...
>>>
>>>I'll give it another quick lookover though, sure.
>>
>>Jeff,
>>
>>As long as 2.4.30 is planned at all, I have no more
>>worries for the moment. But if so, then please don't
>>waste your time looking over the current version. In
>>about a week there should really be another one out.
>>It will add RAID10, and get rid of the "claim disks
>>for RAID" mis-feature. I'll let everybody know, of course.
>
>
> I'm just curious. Is there already a possibility to use
> RAID10 metadata in 2.6.x kernels?
Intel or 'md' metadata?
You need dmraid to use the Intel proprietary format. I'm not sure if it
supports RAID10 yet, but it supports the other levels.
Jeff
On Tue, 18 Jan 2005 16:14:32 -0500, Jeff Garzik <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Tue, 18 Jan 2005 11:56:21 -0800 (PST), Martins Krikis
> > <[email protected]> wrote:
> >
> >>--- Jeff Garzik <[email protected]> wrote:
> >>
> >>
> >>>Check your inbox from months ago ;-) AFAICS his current version
> >>>addresses all the comments from Alan and myself, from when it hit
> >>>lkml 6
> >>>months(?) ago...
> >>>
> >>>I'll give it another quick lookover though, sure.
> >>
> >>Jeff,
> >>
> >>As long as 2.4.30 is planned at all, I have no more
> >>worries for the moment. But if so, then please don't
> >>waste your time looking over the current version. In
> >>about a week there should really be another one out.
> >>It will add RAID10, and get rid of the "claim disks
> >>for RAID" mis-feature. I'll let everybody know, of course.
> >
> >
> > I'm just curious. Is there already a possibility to use
> > RAID10 metadata in 2.6.x kernels?
>
> Intel or 'md' metadata?
Intel
> You need dmraid to use the Intel proprietary format. I'm not sure if it
> supports RAID10 yet, but it supports the other levels.
I know about other levels, I'm asking about RAID10.
--- Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> I'm just curious. Is there already a possibility to use
> RAID10 metadata in 2.6.x kernels?
I don't think so, but provided that dm supports RAID10
it should be quite easy to get there.
Martins Krikis
(not speaking for my employer)
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250