From owner-freebsd-stable Mon May 1 19: 8:49 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 2582237B82B; Mon, 1 May 2000 19:08:45 -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 TAA04945; Mon, 1 May 2000 19:17:01 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005020217.TAA04945@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Parag Patel Cc: dg@root.com, Mike Smith , freebsd-stable@FreeBSD.ORG Subject: Re: How good is AMI MegaRAID support? In-reply-to: Your message of "Mon, 01 May 2000 18:01:26 PDT." <99363.957229286@pinhead.parag.codegen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 May 2000 19:17:01 -0700 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > [Re: BSOD and system crashes, UPS and NVRAM] > > What if the RAID card's onboard software crashes? I don't know enough > about these cards to guess at what's more likely - FreeBSD crashing or > the onboard card software crashing. It's reasonably uncommon - I've only run into a very small handful of cases where I've even *suspected* that I've crashed the card firmware. > Wouldn't any crashes that would toast a filesystem under FBSD care if > the underlying hardware was RAID or a single disk? Wouldn't it still be > toast either way? The issue here is that, in order to achieve decent performance, you need to de-order writes. If you assure that writes are ordered going to stable storage, you can maintain filesystem integrity. If "stable storage" is relatively fast (eg. BB cache), you get a performance win. If "stable storage" is relatively slow, you get a performance loss that you can only trade off by de-ordering writes and thus compromising reliability. > I can see how a NV write-buffer could speed up write performance, but > only if the disk writes are somewhat bursty. It doesn't seem to be very > different from disks with large onboard caches. (Which presumably might > still require a UPS to ride out crashes.) The real utility of the buffer lies in being able to sort and coalesce write operations, as well as reducing the bus traffic. The latter is actually fairly important; in a 3-disk RAID5 array you transfer 100% data to an embedded controller, but you would transfer 150% data if you had already computed the parity and were just sending it to disk. (This picture gets better with more disks, but mirrored disks stay at 200%.) -- \\ 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