Re: Linux: Why software RAID?
Gordon Henderson wrote: On Thu, 24 Aug 2006, Adam Kropelin wrote: Generally speaking the channels on onboard ATA are independant with any vaguely modern card. Ahh, I did not know that. Does this apply to master/slave connections on the same PATA cable as well? I know zero about PATA, but I assumed from the terminology that master and slave needed to cooperate rather closely. I don't know much about co-operation between master slave, but I do know that a failing PATA IDE drive can take out the other one on the same bus - or in my case, render it unusable until I removed the dead drive, whereupon (to my relief) it sprang back into life. This was many many moons ago before I started to use s/w RAID, but it's one thing that would kill a multi-disk array, so I've never done it since. I guess the same could happen on SCSI, but I suspect the interface is a little better designed... Until recently I was working with 38 systems using SCSI RAID controllers (IBM ServeRAID Ultra320). With several types of SCSI drives I saw failures where one drive failed, hung the bus, and caused the next command to another drive to fail. At that point I have to force the controller to think the 2nd drive failed was okay, and then it would recover. I'm told this happens with other hardware, I just haven't personally seen it. From that standpoint, the SATA on the MB look pretty good! -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Alan Cox wrote: Ar Iau, 2006-08-24 am 07:31 -0700, ysgrifennodd Marc Perkel: So - the bottom line answer to my question is that unless you are running raid 5 and you have a high powered raid card with cache and battery backup that there is no significant speed increase to use hardware raid. For raid 0 there is no advantage. If your raid is entirely on PCI plug in cards and you are doing RAID1 there is a speed up using hardware assisted raid because of the PCI bus contention. I would expect to see this with RAID5 as well, for the same reason... -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Bill Davidsen wrote: Alan Cox wrote: Ar Iau, 2006-08-24 am 07:31 -0700, ysgrifennodd Marc Perkel: So - the bottom line answer to my question is that unless you are running raid 5 and you have a high powered raid card with cache and battery backup that there is no significant speed increase to use hardware raid. For raid 0 there is no advantage. If your raid is entirely on PCI plug in cards and you are doing RAID1 there is a speed up using hardware assisted raid because of the PCI bus contention. I would expect to see this with RAID5 as well, for the same reason... assuming you actually have lots of pci contention that might be a consideration... if you're sitting on server class hardware with multiple pci buses or using pci-express cards that won't be a significant issue. -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Furthremore , hw controller are much less feaure rich than sw raid. many different stripe sizes, stripe cache tunning On 25 Aug 2006 23:50:34 -0400, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hardware RAID can be (!= is) more tolerant of serious drive failures where a single drive locks up the bus. A high-end hardware RAID card may be designed with independent controllers so a single drive failure cannot take other spindles down with it. The same can be accomplished with sw RAID of course if the builder is careful to use multiple PCI cards, etc. Sw RAID over your motherboard's onboard controllers leaves you vulnerable. Which is exactly why I *like* SW RAID - I can, and do, have the mirrors span controllers so a whole controller can fail without taking down the system. With HW RAID cards, if your controller dies, you're SOL. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Raz - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
On 8/23/06, H. Peter Anvin [EMAIL PROTECTED] wrote: Chris Friesen wrote: Jeff Garzik wrote: But anyway, to help answer the question of hardware vs. software RAID, I wrote up a page: http://linux.yyz.us/why-software-raid.html Just curious...with these guys (http://www.bigfootnetworks.com/KillerOverview.aspx) putting linux on a PCI NIC to allow them to bypass Windows' network stack, has anyone ever considered doing hardware raid by using an embedded cpu running linux software RAID, with battery-backed memory? It would theoretically allow you to remain feature-compatible by downloading new kernels to your RAID card. Yes. In fact, I have been told by several RAID chip vendors that their customers are *strongly* demanding that their chips be able to run Linux md (and still use whatever hardware offload features.) So it's happening. Speaking of md with hardware offload features: http://prdownloads.sourceforge.net/xscaleiop/ols_paper_2006.pdf?download -hpa Dan - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Hardware RAID can be (!= is) more tolerant of serious drive failures where a single drive locks up the bus. A high-end hardware RAID card may be designed with independent controllers so a single drive failure cannot take other spindles down with it. The same can be accomplished with sw RAID of course if the builder is careful to use multiple PCI cards, etc. Sw RAID over your motherboard's onboard controllers leaves you vulnerable. Which is exactly why I *like* SW RAID - I can, and do, have the mirrors span controllers so a whole controller can fail without taking down the system. With HW RAID cards, if your controller dies, you're SOL. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Richard Scobie wrote: Jeff Garzik wrote: Mark Perkel wrote: Running Linux on an AMD AM2 nVidia chip ser that supports Raid 0 striping on the motherboard. Just wondering if hardware raid (SATA2) is going to be faster that software raid and why? Jeff, on a slightly related note, is the driver status for the NVIDIA as reflected on your site, correct for the new nForce 590/570 AM2 chipset? Unfortunately I rarely have an idea about how marketing names correlate to chipsets. Do you have a PCI ID (lspci -n)? Jeff - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
On Thu, 24 Aug 2006, Adam Kropelin wrote: Generally speaking the channels on onboard ATA are independant with any vaguely modern card. Ahh, I did not know that. Does this apply to master/slave connections on the same PATA cable as well? I know zero about PATA, but I assumed from the terminology that master and slave needed to cooperate rather closely. I don't know much about co-operation between master slave, but I do know that a failing PATA IDE drive can take out the other one on the same bus - or in my case, render it unusable until I removed the dead drive, whereupon (to my relief) it sprang back into life. This was many many moons ago before I started to use s/w RAID, but it's one thing that would kill a multi-disk array, so I've never done it since. I guess the same could happen on SCSI, but I suspect the interface is a little better designed... Gordon - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Jeff Garzik [EMAIL PROTECTED] wrote: But anyway, to help answer the question of hardware vs. software RAID, I wrote up a page: http://linux.yyz.us/why-software-raid.html Generally, you want software RAID unless your PCI bus (or more rarely, your CPU) is getting saturated. With RAID-0, there is no duplication of data, and so, PCI bus and CPU usage should be about the same for hardware and software RAID. Hardware RAID can be (!= is) more tolerant of serious drive failures where a single drive locks up the bus. A high-end hardware RAID card may be designed with independent controllers so a single drive failure cannot take other spindles down with it. The same can be accomplished with sw RAID of course if the builder is careful to use multiple PCI cards, etc. Sw RAID over your motherboard's onboard controllers leaves you vulnerable. --Adam - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Ar Iau, 2006-08-24 am 09:07 -0400, ysgrifennodd Adam Kropelin: Jeff Garzik [EMAIL PROTECTED] wrote: with sw RAID of course if the builder is careful to use multiple PCI cards, etc. Sw RAID over your motherboard's onboard controllers leaves you vulnerable. Generally speaking the channels on onboard ATA are independant with any vaguely modern card. And for newer systems well the motherboard tends to be festooned with random SATA controllers, all separate! - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
On Thu, Aug 24, 2006 at 02:20:50PM +0100, Alan Cox wrote: Ar Iau, 2006-08-24 am 09:07 -0400, ysgrifennodd Adam Kropelin: Jeff Garzik [EMAIL PROTECTED] wrote: with sw RAID of course if the builder is careful to use multiple PCI cards, etc. Sw RAID over your motherboard's onboard controllers leaves you vulnerable. Generally speaking the channels on onboard ATA are independant with any vaguely modern card. Ahh, I did not know that. Does this apply to master/slave connections on the same PATA cable as well? I know zero about PATA, but I assumed from the terminology that master and slave needed to cooperate rather closely. And for newer systems well the motherboard tends to be festooned with random SATA controllers, all separate! And how. You can't swing a dead cat without hitting a half-dozen ATA ports these days. And most of them are those infuriatingly insecure SATA connectors that pop off when you look at them cross-eyed... --Adam - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Adam Kropelin wrote: On Thu, Aug 24, 2006 at 02:20:50PM +0100, Alan Cox wrote: Generally speaking the channels on onboard ATA are independant with any vaguely modern card. Ahh, I did not know that. Does this apply to master/slave connections on the same PATA cable as well? No, it doesn't. Except for cards which use special cables, such as the Pacific Digital ADMA cards (which can even run both master and slave simultaneously on a cable, though not with the current Linux drivers). Cheers - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Ar Iau, 2006-08-24 am 07:31 -0700, ysgrifennodd Marc Perkel: So - the bottom line answer to my question is that unless you are running raid 5 and you have a high powered raid card with cache and battery backup that there is no significant speed increase to use hardware raid. For raid 0 there is no advantage. If your raid is entirely on PCI plug in cards and you are doing RAID1 there is a speed up using hardware assisted raid because of the PCI bus contention. If your controllers are PCI express, on internal high speed busses (eg chipset controllers) or at least half of them are then generally there is no win with hardware raid 0/1 and it is often slower. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Jeff Garzik wrote: Richard Scobie wrote: Jeff, on a slightly related note, is the driver status for the NVIDIA as reflected on your site, correct for the new nForce 590/570 AM2 chipset? Unfortunately I rarely have an idea about how marketing names correlate to chipsets. Do you have a PCI ID (lspci -n)? Unfortunately not, as I am researchiung prior to purchase and Google has not thrown up anything useful. However, the chipset numbers for the nForce 590 are C51Xe and MCP55PXE. I think though, that I have answered the question. According to this NVIDIA page containing a download that appears to be the source from the kernel, These drivers have been fully tested with nForce 570/590. http://www.nvidia.co.uk/object/linux_nforce_1.11_uk.html Regards, Richard - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux: Why software RAID?
Mark Perkel wrote: Running Linux on an AMD AM2 nVidia chip ser that supports Raid 0 striping on the motherboard. Just wondering if hardware raid (SATA2) is going to be faster that software raid and why? First, it sounds like you are confusing motherboard RAID with real RAID. There's a FAQ for this sort of thing: http://linux-ata.org/faq-sata-raid.html In particular, your motherboard's Raid 0 striping (a) is not done in hardware, and (b) has nothing to do with SATA2. But anyway, to help answer the question of hardware vs. software RAID, I wrote up a page: http://linux.yyz.us/why-software-raid.html Generally, you want software RAID unless your PCI bus (or more rarely, your CPU) is getting saturated. With RAID-0, there is no duplication of data, and so, PCI bus and CPU usage should be about the same for hardware and software RAID. Jeff - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Jeff Garzik wrote: Mark Perkel wrote: Running Linux on an AMD AM2 nVidia chip ser that supports Raid 0 striping on the motherboard. Just wondering if hardware raid (SATA2) is going to be faster that software raid and why? Jeff, on a slightly related note, is the driver status for the NVIDIA as reflected on your site, correct for the new nForce 590/570 AM2 chipset? Regards, Richard - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Jeff Garzik wrote: But anyway, to help answer the question of hardware vs. software RAID, I wrote up a page: http://linux.yyz.us/why-software-raid.html Just curious...with these guys (http://www.bigfootnetworks.com/KillerOverview.aspx) putting linux on a PCI NIC to allow them to bypass Windows' network stack, has anyone ever considered doing hardware raid by using an embedded cpu running linux software RAID, with battery-backed memory? It would theoretically allow you to remain feature-compatible by downloading new kernels to your RAID card. Chris - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
Chris Friesen wrote: Jeff Garzik wrote: But anyway, to help answer the question of hardware vs. software RAID, I wrote up a page: http://linux.yyz.us/why-software-raid.html Just curious...with these guys (http://www.bigfootnetworks.com/KillerOverview.aspx) putting linux on a PCI NIC to allow them to bypass Windows' network stack, has anyone ever considered doing hardware raid by using an embedded cpu running linux software RAID, with battery-backed memory? It would theoretically allow you to remain feature-compatible by downloading new kernels to your RAID card. Yes. In fact, I have been told by several RAID chip vendors that their customers are *strongly* demanding that their chips be able to run Linux md (and still use whatever hardware offload features.) So it's happening. -hpa - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux: Why software RAID?
On Wed, 23 Aug 2006, Chris Friesen wrote: Jeff Garzik wrote: But anyway, to help answer the question of hardware vs. software RAID, I wrote up a page: http://linux.yyz.us/why-software-raid.html Just curious...with these guys (http://www.bigfootnetworks.com/KillerOverview.aspx) putting linux on a PCI NIC to allow them to bypass Windows' network stack, has anyone ever considered doing hardware raid by using an embedded cpu running linux software RAID, with battery-backed memory? I'd expect this to be the reason why md offload support to xor engines and whatever turns up. It makes very little sense for a modern server/desktop CPU, but for the embedded ones it does. /Mattias Wadenstein - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
