From owner-freebsd-stable@FreeBSD.ORG Thu Nov 2 15:28:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 409B516A492 for ; Thu, 2 Nov 2006 15:28:13 +0000 (UTC) (envelope-from fredrik.widlund@qbrick.com) Received: from mail.qbrick.com (mail.qbrick.com [62.13.40.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F89143D5A for ; Thu, 2 Nov 2006 15:28:08 +0000 (GMT) (envelope-from fredrik.widlund@qbrick.com) Received: from localhost (localhost [127.0.0.1]) by mail.qbrick.com (Postfix) with ESMTP id CDD7051982; Thu, 2 Nov 2006 16:27:26 +0100 (CET) Received: from mail.qbrick.com ([127.0.0.1]) by localhost (mail0.p0.w0.local [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 71146-03-22; Thu, 2 Nov 2006 16:27:25 +0100 (CET) Received: from [10.43.0.2] (fkwd0.p0.u3.local [10.43.0.2]) by mail.qbrick.com (Postfix) with ESMTP id 26C6A51980; Thu, 2 Nov 2006 16:27:25 +0100 (CET) Message-ID: <454A0E86.6080906@qbrick.com> Date: Thu, 02 Nov 2006 16:28:06 +0100 From: Fredrik Widlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Scott Long References: <45470D95.5020801@qbrick.com> <454718DD.8060108@qbrick.com> <45471ACC.2030604@fer.hr> <4547421D.2010206@qbrick.com> <45477FCC.9050901@qbrick.com> <4547DD7E.4030509@qbrick.com> <20061101210243.GG98766@rancor.immure.com> <4549BF59.3000405@qbrick.com> <454A0054.1060708@samsco.org> In-Reply-To: <454A0054.1060708@samsco.org> X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at qbrick.com Cc: freebsd-stable@freebsd.org Subject: Re: SAS Raid - mfi driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 15:28:13 -0000 Please don't direct this to me as I've already pointed out that I'm not asking about this. Fyi. the cards were shipped in a hurry mistakenly without bbus, we have to wait until next week for them to arrive, and until then we will use cache without batteries since the performance degradation using wthru on fbsd gives us no choice. This is not up for debate here so please let that thread end here and now. In general it's not up to you to decide how people evaluate performance/safety/price ratios. In our case, for example, performance is not an option, regardless of safety. With a 20MB/s bottleneck for writing we can throw the system out the window. Our problem was receiving a card that performed 200MB/s (not using cache) on a different platform, but 20MB/s (not using cache) on fbsd with no apparent or logical explanation as to why. If the fbsd mfi-driver's wthru support comes with a severe performance penalty I suggest the man page mentions it, regardless of whether you think "WThru is a bad thing (tm)" or not. Kind regards, Fredrik Widlund Scott Long wrote: > The battery unit should not be considered optional. It's not about > performance on silly 'dd' tests, it's about data safety. Way back when, > all enterprise RAID cards were sold with an integrated battery because > it was the right thing to do. These days, when you're shopping for RAID > cards, you should just add in the cost of the battery as a > matter-of-fact and not try to skimp by without one. > > Scott > > > Fredrik Widlund wrote: >> Because the card itself will deal with the buffered writes independently >> of the kernel activity the risk should be less than using softupdates. >> Words like "screwed" seems to me to be exaggerated in the generic case. >> I our case specific you would need to understand the nature of what we >> are doing to be able to make a comment like that. For example data is >> redundant (exists in many copies), consists of very large sequencial >> files, we have plenty of backup power, and the greatest risk is fbsd >> locking up/crashing. >> >> Anyway our specific case is not of interest here, I just wanted to share >> our experiences with the LSI MegaSAS with other fbsd users so they >> understand why they get a severe performance degradation if they try to >> use such a card w/o a bbu, and what their options are. >> >> The generic case of how great the risk really is of corrupting >> filesystems completely using caches of any kind on the way to secondary >> storage still is interesting to me, so if you could elaborate here that >> would be great! >> >> Kind regards, >> Fredrik Widlund >> >> >> Bob Willcox wrote: >>> On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: >>> >>>> Yes, it forces writeback even when the controller has no BBU. >>>> Choosing WBack itself will default back to WThru. It's dangerous, >>>> but I guess it should be much less dangerous than using for example >>>> softupdates. >>>> >>> I don't see how it could be *less* dangerous than using softupdates. >>> Any >>> loss of power while writing and it seems to me that you are going to be >>> screwed w/o a BBU. >>> >>> [snip] >>> >>> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >