From owner-freebsd-stable@FreeBSD.ORG Thu Nov 2 15:32:21 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 DDFDF16A40F for ; Thu, 2 Nov 2006 15:32:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DFB643D88 for ; Thu, 2 Nov 2006 15:32:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kA2FVvlW072817; Thu, 2 Nov 2006 08:32:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <454A0F68.7030809@samsco.org> Date: Thu, 02 Nov 2006 08:31:52 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fredrik Widlund 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> <454A0E86.6080906@qbrick.com> In-Reply-To: <454A0E86.6080906@qbrick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org 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:32:21 -0000 You seem convinced that this is a driver bug. Did you receive my series of emails 2 days ago that explained why it is not? Scott Fredrik Widlund wrote: > 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" >> >