From owner-freebsd-stable Mon May 1 15:41: 9 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id 0DCC537B782 for ; Mon, 1 May 2000 15:41:05 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA04152; Mon, 1 May 2000 15:49:21 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005012249.PAA04152@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brad Knowles Cc: freebsd-stable@FreeBSD.ORG Subject: Re: How good is AMI MegaRAID support? In-reply-to: Your message of "Tue, 02 May 2000 00:07:33 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 May 2000 15:49:21 -0700 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I can definitely appreciate that. The RAID solution of choice for > > FreeBSD appears to be SCSI-SCSI RAID adapters as utilized on > > wcarchive.cdrom.com and ftp.freesoftware.org -- the two busiest ftp > > archives around and consequently the two busiest disk subsystems around. > > The testing I've done so far confirms what Greg Lehey and > everyone else has been telling me all this time -- dedicated RAID > controllers just really can't keep up with a good software solution > (such as vinum, or even ccd) and modern hardware. It takes a lot > longer to develop all the custom hardware to put into a RAID > controller, and main CPU speeds have been increasing so fast, that > it's quicker and easier to do it all in software these days. I'd concur with quicker, but easier? Not with Vinum (yet anyway), and certainly not with ccd. And "quicker" only comes into play once you match the I/O capabilities - in most cases, this means several separate SCSI adapters. > Even the megabuck Comparex/Hitachi mainframe-style RAID array > that I've been pounding the snot out of for weeks doesn't reach the > performance levels of the software RAID configuration that Joe Greco > built on top of Adaptec controller and bare 50GB 7200 RPM drives (for > his 1.8TB news spool server), and I have 10kRPM drives and can throw > as much as 4GB of on-board controller RAM at the problem. I can get > reasonably close to his levels of performance, but I haven't been > able to equal them. This would suggest that you're hitting other limits. I seem to recall that you're only using one (or maybe two) host ports on the controller - this will be a bottleneck just for starters. The biggest killer with external RAID units is the miserable bandwidth that you get with just a single or even dual host ports. Fibrechannel can help here, but you really need to look at every part of the system before you start making these sort of judgements. > In fact, to come anywhere *close* to the levels of performance > that Joe has previously mentioned, I've had to add software RAID 0+1 > (in the form of vinum) on top of the hardware RAID-5 (we tested the > other forms of RAID, there doesn't seem to be any noticeable speed > improvement), so that you are striped both horizontally and > vertically. I still haven't heard anything from anyone using embedded RAID adapters. Take some time with eg. an AMI MegaRAID 1600 or (once I'm done with the driver support) something like a 2000 series Mylex controller. Another very important item to bear in mind is that most controller vendors are just starting to wake up to real peformance issues and unix-like operating systems. It wasn't until I explained to Mylex, for example, the inherent badness in a power-of-2 stripe size in conjunction with the FFS disk layout that this even appeared on their radar. Software RAID implementations like Vinum, that were designed from the start to address this, have some definite advantages there. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message