On Sun, 06 May 2012 04:00:46 -0500, Stan Hoeppner wrote: > On 5/3/2012 1:27 PM, Ramon Hofer wrote:
<snipped> > mdraid is quite tolerant with drive errors before it finally kicks them > offline. Using the firmware RAID on this LSI card, any drive showing > flaky behavior will be kicked very quickly from the array, and if you > configure everything properly, you'll receive and email, sms text, or > page telling you a drive is offline and why. If you have a spare > configured, the HBA will automatically start rebuilding the failed > drive's contents to the spare drive. If not, you simply pop the dead > drive out, pop the new on in, and it starts rebuilding automatically. I also had a failure where mdadm told me a drive failed. When I wanted to replace it I had a drive that was some sectors smaller than the array. So I took a closer look at the "broken" one. It seemed ok and I put it back into the array. It's working now for about a year :-) > In a nutshell, (good) hardware RAID typically has every advantage over > linux mdraid but two: > > 1. Flexibility--mdraid can span disks across many HBAs 2. Absolute > performance** > > **Host CPUs are much faster than HBA RAID ASICs, 3-4GHz vs 500-800MHz, > especially with parity calculations (RAID5/6), and have many more cores, > typically 4-24 in a single or dual socket machine, vs 1-2 cores in an > HBA RAID ASIC. Thus they have an enormous raw horsepower advantage. A > good hardware RAID HBA will have RAID5/6 performance similar to mdraid > w/up to ~16-24 SAS 15K drives. At some drive count beyond that the RAID > ASIC will hit its performance ceiling. > > Many people use hybrid setups, where hardware RAID is used at the > controller level and mdraid is used to span the HW RAID devices into a > single Linux disk device, allowing for a single filesystem across dozens > of drives connected to 2, 4, or more RAID HBAs. With some application > workloads multiple RAID groups are created per controller and these are > then spanned or striped with md, for example high IOPS maildir servers. > > You mentioned previously you don't have a high performance requirement > in which case I'd recommend hardware RAID. That said, if you want to > use RAID5/6 instead of RAID10, md RAID may be more attractive, as the > parity RAID performance of the SAS9240 is less than stellar. Depending > on your workloads, it may perform great. Just remember that the LSI > SAS9240 is high end JBOD HBA with RAID firmware. It's can act just like > a HW RAID card from the viewpoint of the OS and the user, but it not a > HW RAID card. It's not even an entry level RAID controller--note the > lack of cache and BBU option. > > Given what you've told us so far, I'd say you'd likely be very happy > using the HW RAID mode. I don't know if I understand correctly what you wrote: You say that the LSI SAS9240 is slower for raid 5 than mdadm? And less flexible? How about CLI manage possibilities? Will I have to reboot when I want to set up a new array? Can I check the progress of the rebuilding process? Even though I know raid 5 is risky with 2 TB drives I think it's probably the best solution for me. I don't want to loose too much storage space by limiting the 2 TB drives to 1.5 TB to fit the smaller drive size. And still would like to have a little parity safety. But I haven't thought about putting the raid 5 arrays in another raid0 array. I was thinking about lvm... But this shouldn't make much difference? Only that I'm already a bit familiar with mdadm not with lvm... >> Or if I ever want to exchange the mainboard and use one with a SAS >> controller onboard? > > If your new mobo has an onboard SAS controller it will be an LSI > controller, so this is a non issue. But why would you switch to that > and toss the 9240 anyway? They use the same ASIC: the SAS2008. Look > at SuperMicro, Tyan, Intel, and Asus boards. They all use the SAS2008, > or an older or newer LSI SAS chip. > > LSI is the only viable motherboard-down SAS solution on the market, at > least on quality server mobos. There may be junk floating around the > Asian markets with different onboard SAS chips. If so, I'm unaware of > them, and I'd recommend to anyone to stay away from them as the chips > will be Marvell, JMicron, etc--cheap and unreliable. I don't want to do that in the near future. But I don't know what will be in 5 or even 10 years. What I know is that I hopefully still can use the case and the drives (at least most of them :-) ). Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jo5o02$540$1...@dough.gmane.org
