Hi there,
I have an IBM x346 with some Adaptec 7902 SCSI controllers; one has HostRAID
enabled in a RAID array, and the other does not. Upon bootup, the aic79xx
driver will grab both controllers even though I'd prefer that Adaptec's a320raid
driver grab the HostRAID controller. (When attached to the RAID array, the
aic79xx driver presents each drive in the array as a separate SCSI device.) If
HostRAID is turned on, the PCI class code is 0x0104 (RAID) and if it's turned
off, the class code is 0x0100 (SCSI).
Unfortunately, there currently is no provision in the aic79xx driver to ignore
RAID controllers--if the PCI device/vendor IDs match, the driver takes the
controller. The attached patch modifies the PCI probe function to ignore RAID
controllers and a module parameter "attach_HostRAID" to toggle this behavior.
If one passes "attach_HostRAID=1" to insmod, the driver will take RAID
controllers; "attach_HostRAID=0", it won't. The default is to set it to zero.
The patch should apply cleanly against 2.6.14 and I've verified that it works
correctly on a x346 and a x226, both of which have a 7902b. I'd appreciate a
few more eyes to look over it, and if there aren't any objections I'd like to
submit this for inclusion in mainline.
--Darrick
--------------------------
Signed-Off-By: Darrick Wong <[email protected]>
diff -Naurp orig/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
linux-2.6.14.3/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
--- orig/drivers/scsi/aic7xxx/aic79xx_osm_pci.c 2005-11-24 14:10:21.000000000 -0800
+++ linux-2.6.14.3/drivers/scsi/aic7xxx/aic79xx_osm_pci.c 2005-11-29
16:54:30.000000000 -0800
@@ -43,6 +43,12 @@
#include "aic79xx_inline.h"
#include "aic79xx_pci.h"
+static int attach_HostRAID = 0;
+module_param_named(attach_HostRAID, attach_HostRAID, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(attach_HostRAID, "\n"
+ "\tEnable(1) or disable(0) attaching to HostRAID enabled host "
+ "adapters.\n\tDefault: 0");
+
static int ahd_linux_pci_dev_probe(struct pci_dev *pdev,
const struct pci_device_id *ent);
static int ahd_linux_pci_reserve_io_regions(struct ahd_softc *ahd,
@@ -132,6 +138,14 @@ ahd_linux_pci_dev_probe(struct pci_dev *
char *name;
int error;
+ /* Ignore hostraid controllers unless the override is on. */
+ if (pdev->class == (PCI_CLASS_STORAGE_RAID << 8) && !attach_HostRAID) {
+ printk(KERN_INFO "aic79xx: will not attach to HostRAID enabled"
+ " device %s unless attach_HostRAID parameter is set\n",
+ pci_name(pdev));
+ return -ENODEV;
+ }
+
pci = pdev;
entry = ahd_find_pci_device(pci);
if (entry == NULL)
Darrick J. Wong wrote:
> Hi there,
>
> I have an IBM x346 with some Adaptec 7902 SCSI controllers; one has HostRAID
> enabled in a RAID array, and the other does not. Upon bootup, the aic79xx
> driver will grab both controllers even though I'd prefer that Adaptec's a320raid
> driver grab the HostRAID controller. (When attached to the RAID array, the
> aic79xx driver presents each drive in the array as a separate SCSI device.) If
> HostRAID is turned on, the PCI class code is 0x0104 (RAID) and if it's turned
> off, the class code is 0x0100 (SCSI).
>
> Unfortunately, there currently is no provision in the aic79xx driver to ignore
> RAID controllers--if the PCI device/vendor IDs match, the driver takes the
> controller.
This is the correct behavior. Under Linux, the driver should export
only the underlying hardware, and nothing more. This is how all the
SATA controller drivers function, and this is how aic79xx functions.
Use a tool such as 'dmraid' for vendor-proprietary RAID solutions.
Your patch is therefore strongly NAK'd.
Jeff
> Upon bootup, the aic79xx
> driver will grab both controllers even though I'd prefer that Adaptec's a320raid
> driver grab the HostRAID controller.
where is the sourcecode for the a320raid driver?
afaik dmraid supports this format already, and if not I would urge you
to help the dmraid project to support it instead..
Jeff,
Good, this was the exact response that I was hoping for, as I've been told to
convince Adaptec to drop the binary RAID drivers in favor of helping out dmraid
development instead. That process will probably be difficult, but at least I
now have incontrovertible proof that nobody will bend over backwards to support
them and that dmraid is the way to go. Not that I'm terribly surprised by this.
I would, however, like to apologize for all this churlishness. Hopefully some
day I won't have to deal with these binary modules altogether, and I won't have
to resort to such methods to get vendors to Do the Right Thing(tm).
--D
(A pity that dmraid doesn't do hostraid right now, otherwise none of this would
be necessary.)
Jeff Garzik wrote:
> This is the correct behavior. Under Linux, the driver should export
> only the underlying hardware, and nothing more. This is how all the
> SATA controller drivers function, and this is how aic79xx functions.
>
> Use a tool such as 'dmraid' for vendor-proprietary RAID solutions.
>
> Your patch is therefore strongly NAK'd.
>
> Jeff
On Wed, Nov 30, 2005 at 09:57:49PM -0800, Darrick J. Wong wrote:
> Hi there,
>
> I have an IBM x346 with some Adaptec 7902 SCSI controllers; one has HostRAID
> enabled in a RAID array, and the other does not. Upon bootup, the aic79xx
> driver will grab both controllers even though I'd prefer that Adaptec's a320raid
> driver grab the HostRAID controller. (When attached to the RAID array, the
> aic79xx driver presents each drive in the array as a separate SCSI device.) If
> HostRAID is turned on, the PCI class code is 0x0104 (RAID) and if it's turned
> off, the class code is 0x0100 (SCSI).
>
> Unfortunately, there currently is no provision in the aic79xx driver to ignore
> RAID controllers--if the PCI device/vendor IDs match, the driver takes the
> controller. The attached patch modifies the PCI probe function to ignore RAID
> controllers and a module parameter "attach_HostRAID" to toggle this behavior.
> If one passes "attach_HostRAID=1" to insmod, the driver will take RAID
> controllers; "attach_HostRAID=0", it won't. The default is to set it to zero.
>
> The patch should apply cleanly against 2.6.14 and I've verified that it works
> correctly on a x346 and a x226, both of which have a 7902b. I'd appreciate a
> few more eyes to look over it, and if there aren't any objections I'd like to
> submit this for inclusion in mainline.
NACK. We're not going to support attaching broken propritary drivers.
Sepcially as these "HostRAID" cards are plain SCSI HBAs. If you care about
botting from the bios softraid port the adaptec raid format support to dmraid.
Christoph Hellwig sez:
> NACK. We're not going to support attaching broken propritary drivers.
Understood and expected.
The word 'broken' is hardly chosen for scientific reasons, bespeaks an
agenda ;-> Just because you can not see the code, does not mean it is
broken.
I have on numerous attempts tried to contact Heinz Mauelshagen to
fortify dmraid in support of the HostRAID adapters. He has yet to
respond to my emails to start a dialogue with Adaptec.
Justin Gibbs had provided the community the emd driver, soundly rejected
and never ported to dm because there were features that Justin held dear
in md that do not translate to dm. An unfortunate waste of considerable
resources.
Without the timely agenda and cooled temperaments to close the gap, the
solution should be temporarily to support the proprietary HostRAID
driver when the Adapter is in HostRAID mode and we continue to work to
close that gap on dmraid.
Could you agree with that to help the users today?
[ You are on record as not giving a fig for the users, what if I showed
them as starving children in a third world nation, would that melt your
heart? ;-} ]
> Sepcially as these "HostRAID" cards are plain SCSI HBAs.
They are plain SCSI HBAs, but are designated as a RAID card rather than
a Host Bus Adapter in the PCI config space when in 'HostRAID' mode. The
fact that is designated in the PCI space should be enough reason *not*
to attach a simplified LLD.
The HostRAID driver has a specialized (ok, yes, also proprietary) CHIM
and sequencer where attention can be focused on techniques of
performance improvement and OS agnostics. In addition, the RAID code in
that driver understands the hardware, CHIM & sequencer and takes
advantage of features that just can not be performed by an abstracted dm
or an LLD. RAID1 is handled under some conditions, for instance, with
one DMA operation over the PCI bus rather than two duplicated for each
target, greatly increasing the performance.
Linux is not about performance first, it is about doing it the Linux
way. I believe we can understand that. And in turn, do not consider it
harmful if a group of individuals trying to make a living see a chance
to acquire a competitive edge.
Sincerely -- Mark Salyzyn
> [ You are on record as not giving a fig for the users, what if I showed
> them as starving children in a third world nation, would that melt your
> heart? ;-} ]
adaptec could just release the source of the enhancement to linux (as
the GPL basically requires anyway :)
On Thu, Dec 01, 2005 at 08:44:15AM -0500, Salyzyn, Mark wrote:
> Christoph Hellwig sez:
> > NACK. We're not going to support attaching broken propritary drivers.
>
> Understood and expected.
>
> The word 'broken' is hardly chosen for scientific reasons, bespeaks an
> agenda ;-> Just because you can not see the code, does not mean it is
> broken.
>
> I have on numerous attempts tried to contact Heinz Mauelshagen to
> fortify dmraid in support of the HostRAID adapters. He has yet to
> respond to my emails to start a dialogue with Adaptec.
None of those here.
Please forward.
>
> Justin Gibbs had provided the community the emd driver, soundly rejected
> and never ported to dm because there were features that Justin held dear
> in md that do not translate to dm. An unfortunate waste of considerable
> resources.
>
> Without the timely agenda and cooled temperaments to close the gap, the
> solution should be temporarily to support the proprietary HostRAID
> driver when the Adapter is in HostRAID mode and we continue to work to
> close that gap on dmraid.
>
> Could you agree with that to help the users today?
>
> [ You are on record as not giving a fig for the users, what if I showed
> them as starving children in a third world nation, would that melt your
> heart? ;-} ]
>
> > Sepcially as these "HostRAID" cards are plain SCSI HBAs.
>
> They are plain SCSI HBAs, but are designated as a RAID card rather than
> a Host Bus Adapter in the PCI config space when in 'HostRAID' mode. The
> fact that is designated in the PCI space should be enough reason *not*
> to attach a simplified LLD.
>
> The HostRAID driver has a specialized (ok, yes, also proprietary) CHIM
> and sequencer where attention can be focused on techniques of
> performance improvement and OS agnostics. In addition, the RAID code in
> that driver understands the hardware, CHIM & sequencer and takes
> advantage of features that just can not be performed by an abstracted dm
> or an LLD. RAID1 is handled under some conditions, for instance, with
> one DMA operation over the PCI bus rather than two duplicated for each
> target, greatly increasing the performance.
>
> Linux is not about performance first, it is about doing it the Linux
> way. I believe we can understand that. And in turn, do not consider it
> harmful if a group of individuals trying to make a living see a chance
> to acquire a competitive edge.
>
> Sincerely -- Mark Salyzyn
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Red Hat GmbH
Consulting Development Engineer Am Sonnenhang 11
Cluster and Storage Development 56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Thu, Dec 01, 2005 at 08:44:15AM -0500, Salyzyn, Mark wrote:
> Christoph Hellwig sez:
> > NACK. We're not going to support attaching broken propritary drivers.
>
> Understood and expected.
>
> The word 'broken' is hardly chosen for scientific reasons, bespeaks an
> agenda ;-> Just because you can not see the code, does not mean it is
> broken.
there's various bugreports all over. Having no source to disprove that
it's broken I call it broken for now.
> I have on numerous attempts tried to contact Heinz Mauelshagen to
> fortify dmraid in support of the HostRAID adapters. He has yet to
> respond to my emails to start a dialogue with Adaptec.
What about just sending him patches?
> Without the timely agenda and cooled temperaments to close the gap, the
> solution should be temporarily to support the proprietary HostRAID
> driver when the Adapter is in HostRAID mode and we continue to work to
> close that gap on dmraid.
No. we're not going to do anything to make life for binary module easier,
quite contrary.
> > Sepcially as these "HostRAID" cards are plain SCSI HBAs.
>
> They are plain SCSI HBAs, but are designated as a RAID card rather than
> a Host Bus Adapter in the PCI config space when in 'HostRAID' mode. The
> fact that is designated in the PCI space should be enough reason *not*
> to attach a simplified LLD.
No.
>
> The HostRAID driver has a specialized (ok, yes, also proprietary) CHIM
> and sequencer where attention can be focused on techniques of
> performance improvement and OS agnostics. In addition, the RAID code in
> that driver understands the hardware, CHIM & sequencer and takes
> advantage of features that just can not be performed by an abstracted dm
> or an LLD. RAID1 is handled under some conditions, for instance, with
> one DMA operation over the PCI bus rather than two duplicated for each
> target, greatly increasing the performance.
If you contributed that sequencer code and sent me a card I'm pretty sure
I'd love into adding support for this to a special DM module. In fact we'd
need somthing similar for Certain SATA boards aswell.
OTOH the raid flag would be useless aswell there, because we'd of course
support this on identical cards without the raid bios aswell :)
Salyzyn, Mark wrote:
> Justin Gibbs had provided the community the emd driver, soundly rejected
> and never ported to dm because there were features that Justin held dear
> in md that do not translate to dm. An unfortunate waste of considerable
> resources.
All throughout development, before Justin had written a single line of
code, he was told to do things via Device Mapper. All he had to do was
open his ears, and no resource waste would have occurred.
> Without the timely agenda and cooled temperaments to close the gap, the
> solution should be temporarily to support the proprietary HostRAID
> driver when the Adapter is in HostRAID mode and we continue to work to
> close that gap on dmraid.
[...]
> They are plain SCSI HBAs, but are designated as a RAID card rather than
> a Host Bus Adapter in the PCI config space when in 'HostRAID' mode. The
> fact that is designated in the PCI space should be enough reason *not*
> to attach a simplified LLD.
Strongly disagree.
Linux should export the [non-RAID] hardware capabilities, nothing more.
We don't shim for not-in-tree binary-only drivers. A user continues to
be free to simply -not use- aic79xx, regardless of this design decision.
SATA controllers come with all sorts of class codes: RAID (host/fake
raid), SCSI (fake RAID/fake scsi), IDE, Serial ATA.
We ignore that, and just export the hardware. The class code is only a
hint that dmraid should be loaded on top of the low-level driver.
> Linux is not about performance first, it is about doing it the Linux
> way. I believe we can understand that. And in turn, do not consider it
> harmful if a group of individuals trying to make a living see a chance
> to acquire a competitive edge.
We don't do it "the Linux way" just for NIH's sake. There are strong
reasons why we want cross-vendor solutions. There are strong reasons
why we don't want every driver to embed a software RAID engine inside
it. And there are strong reasons (some legal, not technical) why its
best to ignore binary-only, out-of-tree drivers.
Jeff
On Thu, Dec 01, 2005 at 05:44:12PM +0000, Christoph Hellwig wrote:
> On Thu, Dec 01, 2005 at 08:44:15AM -0500, Salyzyn, Mark wrote:
> > The HostRAID driver has a specialized (ok, yes, also proprietary) CHIM
> > and sequencer where attention can be focused on techniques of
> > performance improvement and OS agnostics. In addition, the RAID code in
> > that driver understands the hardware, CHIM & sequencer and takes
> > advantage of features that just can not be performed by an abstracted dm
> > or an LLD. RAID1 is handled under some conditions, for instance, with
> > one DMA operation over the PCI bus rather than two duplicated for each
> > target, greatly increasing the performance.
>
> If you contributed that sequencer code and sent me a card I'm pretty sure
> I'd love into adding support for this to a special DM module. In fact we'd
> need somthing similar for Certain SATA boards aswell.
>
> OTOH the raid flag would be useless aswell there, because we'd of course
> support this on identical cards without the raid bios aswell :)
I'd love to see a hardware-aware DM RAID module, since I want to do the
same thing for sata_sx4 (Promise SX4).
SX4 has four ATA engines, an on-card ECC-capable DIMM, and an on-card
XOR engine. The OS driver has complete control over these facilities.
Unfortunately, driving the card in "dumb mode" means that performance
takes a major hit, since each transaction looks like:
submit DMA memcpy to HDMA engine
get HDMA interrupt
# now, the data is on the card
submit ATA write command
get ATA interrupt
All data must be copied to/from the DIMM, before the ATA engine can do
anything. Further, there is only one HDMA engine, but 4 ATA engines.
Ideally, RAID1 would copy the data to the card ONCE, then start 2 ATA
engines. Ideally, RAID5 would copy the data to the card ONCE, XOR it,
then start the ATA engines. And the rest of the DIMM should be used as
write-through cache.
I'm sure DM can do that, but I haven't researched how.
I'll supply a card (and engineering help, but no docs, alas) to anyone
interested in trying out this stuff.
Jeff
Jeff Garzik [mailto:[email protected]] sez:
> All throughout development, before Justin had written a
> single line of code, he was told to do things via Device Mapper.
He did not strictly write the emd code, it was written years earlier by
a team. It's release was the result of it being placed on his lap
submit.
As I said, it all ended up being an unfortunate timing of events with
unexpected side effects. At each instant of time it has always been
clear what to do ...
2005? We tried to set up a case for ROI for the support of a dmraid
plugin. I am merely a JAFO to that process trying to push it along.
Sincerely -- Mark Salyzyn
Salyzyn, Mark wrote:
> Jeff Garzik [mailto:[email protected]] sez:
>
>>All throughout development, before Justin had written a
>>single line of code, he was told to do things via Device Mapper.
>
>
> He did not strictly write the emd code, it was written years earlier by
> a team. It's release was the result of it being placed on his lap
> submit.
Ah, I stand corrected.
I just recall being on concalls months prior to public EMD release,
urging the use of Device Mapper, and telling Adaptec and other involved
companies that the submission would be rejected if the current course
was continued.
No doubt it was very frustrating for the engineers doing the work to
have their months of effort rejected, but it was also frustrating for
me, since I was trying make all parties aware of the impending rejection
well in advance.
> As I said, it all ended up being an unfortunate timing of events with
> unexpected side effects. At each instant of time it has always been
> clear what to do ...
>
> 2005? We tried to set up a case for ROI for the support of a dmraid
> plugin. I am merely a JAFO to that process trying to push it along.
Well, all your efforts are appreciated :)
Adaptec has an unfortunate history of simply not communicating well with
the Linux community -- and I note that's a two-way street. I've even
heard it whispered that Linux people "hate Adaptec", that we take some
sort of pleasure out of putting the screws to Adaptec.
Nothing could be further from the truth.
Exclusing you, Mark, who seems to understand this stuff, Adaptec just
seems to have a tough time understanding the rationale and goals behind
the feedback from SCSI and Linux maintainers.
Adaptec -- excluding aacraid -- continues to have a history of (a) being
grossly dissatisfied with the current SCSI code, and (b) concluding that
a proper solution simply works around all the problems. That's a fair
perspective, but Linux prefers the more cross-vendor approach of
modifying the base Linux code.
Greater than Linux itself, the GPL and open source create a commodity
effect: competitors work on the same piece of software, rather than
producing competing versions of software. Out of this principle falls
the "update SCSI core, don't workaround in your driver" approach. Ditto
for use of Device Mapper, rather than doing RAID in the driver itself,
or duplicating effort with EMD. With open source, code duplication just
increases effort, decreases test coverage, and increases the likelihood
of bugs.
The downside (from a vendor perspective) is that vendor engineers are
drafted into updating the Linux core, when a new spiffy hardware feature
needs to be supported. This is actually not a downside, but a benefit.
In the long run, common code is highly reus{able,ed}, leading to
rapid development, vastly increased test coverage, and maintainable even
if the original hardware vendor goes out of business, or EOLs the hardware.
I wish I could rewind the clock, and demonstrate to Justin, Scott, Luben
and other Adaptec engineers that there are solid reasons behind each of
these decisions, and its not "politics" or "NIH" or "we hate you" or "we
are the anointed ones, bow to us."
Linux doesn't have a roadmap, rather it has certain code patterns that
experience has taught us are sustainable, portable, and performant in
the long term. As long as new source code fits these code patterns, we
welcome the addition with open arms. From any company.
Jeff
Darrick J. Wong wrote:
> Jeff,
>
> Good, this was the exact response that I was hoping for, as I've been told to
> convince Adaptec to drop the binary RAID drivers in favor of helping out dmraid
> development instead. That process will probably be difficult, but at least I
> now have incontrovertible proof that nobody will bend over backwards to support
> them and that dmraid is the way to go. Not that I'm terribly surprised by this.
It's good that there is a push to get non-binary-module support for
these controllers in Linux. It's a shame that this is only happening now
though.
It does rather suck that IBM changed to use this AIC79xx controller with
"HostRAID" in the x346, x236, etc. servers. The last generation of
servers (x235, x345) used an LSI Logic MPT Fusion controller which could
do RAID 1 in hardware (or at least firmware) without a special driver -
this sufficed for certain applications. With the new machines, RAID on
the onboard controller requires using the stupid binary module which is
only built against certain specific kernels, or using pure software RAID..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Thu, 01 Dec 2005, Heinz Mauelshagen wrote:
> On Thu, Dec 01, 2005 at 08:44:15AM -0500, Salyzyn, Mark wrote:
> > Christoph Hellwig sez:
> > > NACK. We're not going to support attaching broken propritary drivers.
> >
> > Understood and expected.
> >
> > The word 'broken' is hardly chosen for scientific reasons, bespeaks an
> > agenda ;-> Just because you can not see the code, does not mean it is
> > broken.
> >
> > I have on numerous attempts tried to contact Heinz Mauelshagen to
> > fortify dmraid in support of the HostRAID adapters. He has yet to
> > respond to my emails to start a dialogue with Adaptec.
>
> None of those here.
> Please forward.
I also sent an email a few weeks ago and haven't heard back yet.
In my message I asked whether it was feasible for you to look at
FreeBSD's "ataraid(4)" driver to learn the Intel ICHx-R SoftRAID format.
I know FreeBSD understands this format, and dmraid did not when I sent
the email.
The hardware I was looking at is ICH7-R. It only works in compatibility
mode, which only saw one drive for some reason.
Bottom line: 3Ware Escalade are cheap enough not to bother with this
SoftRAID stuff...
--
Matthias Andree
Matthias Andree wrote:
> In my message I asked whether it was feasible for you to look at
> FreeBSD's "ataraid(4)" driver to learn the Intel ICHx-R SoftRAID format.
> I know FreeBSD understands this format, and dmraid did not when I sent
> the email.
Read the readme :)
http://people.redhat.com/~heinzm/sw/dmraid/readme
The following ATARAID types are supported:
Highpoint HPT37X
Highpoint HPT45X
Intel Software RAID
[...]
On Sat, 03 Dec 2005, Jeff Garzik wrote:
> Matthias Andree wrote:
> >In my message I asked whether it was feasible for you to look at
> >FreeBSD's "ataraid(4)" driver to learn the Intel ICHx-R SoftRAID format.
> >I know FreeBSD understands this format, and dmraid did not when I sent
> >the email.
>
> Read the readme :)
>
> http://people.redhat.com/~heinzm/sw/dmraid/readme
>
> The following ATARAID types are supported:
>
> Highpoint HPT37X
> Highpoint HPT45X
> Intel Software RAID
> [...]
I know it claimed support, but didn't appear to work for me (kernel
2.6.13 as on SUSE 10.0, ICH7-R chipset).
What good is this readme if "dmraid -s" doesn't come up with anything?
I cannot recreate the problem any more, as the machine, as I wrote, has
moved forward to an Escalade 8000 series controller (it's more
convenient anyhow).
Attached my original message from 4 weeks ago.
--
Matthias Andree
All,
At last, I've been given the go-ahead to work on hostraid support for
dmraid. I'll post some patches when I've made some progress.
Is linux-lvm the appropriate place for dmraid patches/discussion? I
couldn't find any mailing lists that sounded more appropriate.
--D
Jeff Garzik wrote:
> Salyzyn, Mark wrote:
>
>> Jeff Garzik [mailto:[email protected]] sez:
>>
>>> All throughout development, before Justin had written a single line
>>> of code, he was told to do things via Device Mapper.
>>
>>
>>
>> He did not strictly write the emd code, it was written years earlier by
>> a team. It's release was the result of it being placed on his lap
>> submit.
>
>
> Ah, I stand corrected.
>
> I just recall being on concalls months prior to public EMD release,
> urging the use of Device Mapper, and telling Adaptec and other involved
> companies that the submission would be rejected if the current course
> was continued.
>
> No doubt it was very frustrating for the engineers doing the work to
> have their months of effort rejected, but it was also frustrating for
> me, since I was trying make all parties aware of the impending rejection
> well in advance.
>
>
>> As I said, it all ended up being an unfortunate timing of events with
>> unexpected side effects. At each instant of time it has always been
>> clear what to do ...
>>
>> 2005? We tried to set up a case for ROI for the support of a dmraid
>> plugin. I am merely a JAFO to that process trying to push it along.
>
>
> Well, all your efforts are appreciated :)
>
> Adaptec has an unfortunate history of simply not communicating well with
> the Linux community -- and I note that's a two-way street. I've even
> heard it whispered that Linux people "hate Adaptec", that we take some
> sort of pleasure out of putting the screws to Adaptec.
>
> Nothing could be further from the truth.
>
> Exclusing you, Mark, who seems to understand this stuff, Adaptec just
> seems to have a tough time understanding the rationale and goals behind
> the feedback from SCSI and Linux maintainers.
>
> Adaptec -- excluding aacraid -- continues to have a history of (a) being
> grossly dissatisfied with the current SCSI code, and (b) concluding that
> a proper solution simply works around all the problems. That's a fair
> perspective, but Linux prefers the more cross-vendor approach of
> modifying the base Linux code.
>
> Greater than Linux itself, the GPL and open source create a commodity
> effect: competitors work on the same piece of software, rather than
> producing competing versions of software. Out of this principle falls
> the "update SCSI core, don't workaround in your driver" approach. Ditto
> for use of Device Mapper, rather than doing RAID in the driver itself,
> or duplicating effort with EMD. With open source, code duplication just
> increases effort, decreases test coverage, and increases the likelihood
> of bugs.
>
> The downside (from a vendor perspective) is that vendor engineers are
> drafted into updating the Linux core, when a new spiffy hardware feature
> needs to be supported. This is actually not a downside, but a benefit.
> In the long run, common code is highly reus{able,ed}, leading to
> rapid development, vastly increased test coverage, and maintainable even
> if the original hardware vendor goes out of business, or EOLs the hardware.
>
> I wish I could rewind the clock, and demonstrate to Justin, Scott, Luben
> and other Adaptec engineers that there are solid reasons behind each of
> these decisions, and its not "politics" or "NIH" or "we hate you" or "we
> are the anointed ones, bow to us."
>
> Linux doesn't have a roadmap, rather it has certain code patterns that
> experience has taught us are sustainable, portable, and performant in
> the long term. As long as new source code fits these code patterns, we
> welcome the addition with open arms. From any company.
>
> Jeff
>
>
>
Darrick J. Wong wrote:
> All,
>
> At last, I've been given the go-ahead to work on hostraid support for
> dmraid. I'll post some patches when I've made some progress.
Great!
> Is linux-lvm the appropriate place for dmraid patches/discussion? I
> couldn't find any mailing lists that sounded more appropriate.
I think its dm-devel. I googled for 'dm-devel' and it brought up the
postman mailing list info.
Jeff
On Mon, Dec 05, 2005 at 01:06:41PM -0800, Darrick J. Wong wrote:
> All,
>
> At last, I've been given the go-ahead to work on hostraid support for
> dmraid. I'll post some patches when I've made some progress.
Very good.
Looking forward to your contribution to dmraid.
>
> Is linux-lvm the appropriate place for dmraid patches/discussion? I
> couldn't find any mailing lists that sounded more appropriate.
[email protected] for dmraid.
dm-devel for device-mapper.
Regards,
Heinz -- The LVM Guy --
>
> --D
>
> Jeff Garzik wrote:
> > Salyzyn, Mark wrote:
> >
> >> Jeff Garzik [mailto:[email protected]] sez:
> >>
> >>> All throughout development, before Justin had written a single line
> >>> of code, he was told to do things via Device Mapper.
> >>
> >>
> >>
> >> He did not strictly write the emd code, it was written years earlier by
> >> a team. It's release was the result of it being placed on his lap
> >> submit.
> >
> >
> > Ah, I stand corrected.
> >
> > I just recall being on concalls months prior to public EMD release,
> > urging the use of Device Mapper, and telling Adaptec and other involved
> > companies that the submission would be rejected if the current course
> > was continued.
> >
> > No doubt it was very frustrating for the engineers doing the work to
> > have their months of effort rejected, but it was also frustrating for
> > me, since I was trying make all parties aware of the impending rejection
> > well in advance.
> >
> >
> >> As I said, it all ended up being an unfortunate timing of events with
> >> unexpected side effects. At each instant of time it has always been
> >> clear what to do ...
> >>
> >> 2005? We tried to set up a case for ROI for the support of a dmraid
> >> plugin. I am merely a JAFO to that process trying to push it along.
> >
> >
> > Well, all your efforts are appreciated :)
> >
> > Adaptec has an unfortunate history of simply not communicating well with
> > the Linux community -- and I note that's a two-way street. I've even
> > heard it whispered that Linux people "hate Adaptec", that we take some
> > sort of pleasure out of putting the screws to Adaptec.
> >
> > Nothing could be further from the truth.
> >
> > Exclusing you, Mark, who seems to understand this stuff, Adaptec just
> > seems to have a tough time understanding the rationale and goals behind
> > the feedback from SCSI and Linux maintainers.
> >
> > Adaptec -- excluding aacraid -- continues to have a history of (a) being
> > grossly dissatisfied with the current SCSI code, and (b) concluding that
> > a proper solution simply works around all the problems. That's a fair
> > perspective, but Linux prefers the more cross-vendor approach of
> > modifying the base Linux code.
> >
> > Greater than Linux itself, the GPL and open source create a commodity
> > effect: competitors work on the same piece of software, rather than
> > producing competing versions of software. Out of this principle falls
> > the "update SCSI core, don't workaround in your driver" approach. Ditto
> > for use of Device Mapper, rather than doing RAID in the driver itself,
> > or duplicating effort with EMD. With open source, code duplication just
> > increases effort, decreases test coverage, and increases the likelihood
> > of bugs.
> >
> > The downside (from a vendor perspective) is that vendor engineers are
> > drafted into updating the Linux core, when a new spiffy hardware feature
> > needs to be supported. This is actually not a downside, but a benefit.
> > In the long run, common code is highly reus{able,ed}, leading to
> > rapid development, vastly increased test coverage, and maintainable even
> > if the original hardware vendor goes out of business, or EOLs the hardware.
> >
> > I wish I could rewind the clock, and demonstrate to Justin, Scott, Luben
> > and other Adaptec engineers that there are solid reasons behind each of
> > these decisions, and its not "politics" or "NIH" or "we hate you" or "we
> > are the anointed ones, bow to us."
> >
> > Linux doesn't have a roadmap, rather it has certain code patterns that
> > experience has taught us are sustainable, portable, and performant in
> > the long term. As long as new source code fits these code patterns, we
> > welcome the addition with open arms. From any company.
> >
> > Jeff
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Red Hat GmbH
Consulting Development Engineer Am Sonnenhang 11
Cluster and Storage Development 56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Iau, 2005-12-01 at 08:44 -0500, Salyzyn, Mark wrote:
> I have on numerous attempts tried to contact Heinz Mauelshagen to
> fortify dmraid in support of the HostRAID adapters. He has yet to
> respond to my emails to start a dialogue with Adaptec.
That suprises me. Heinz does respond to things and actively asks for
help on stuff like dmraid
> Justin Gibbs had provided the community the emd driver, soundly rejected
> and never ported to dm because there were features that Justin held dear
> in md that do not translate to dm. An unfortunate waste of considerable
> resources.
Please understand Justin Gibbs gave the Linux community emd in about as
productive a way that the US/UK government "gave" Iraq democracy.
Whatever the reasons for that and where the fault lies is another matter
but the result was not productive.
For long term maintenance and sanity reasons Linux is about doing things
in a logical consistent manner. Many people have had to learn to do
things the way Linus wants or the kernel expects, me included. It is
from that sort of process we have the current excellent e100 ethernet
driver still from Intel but not at all the Intel original for example.
We've consistently avoided hiding software raid behind magical
abstractions. There are numerous reasons for this. We want disks to move
between controllers easily for example, which vendors usually want to
make as painful as possible to create lockin.