From owner-freebsd-stable@FreeBSD.ORG Thu Nov 2 15:55:07 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 637C116A40F for ; Thu, 2 Nov 2006 15:55:07 +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 0F5F943D99 for ; Thu, 2 Nov 2006 15:54:43 +0000 (GMT) (envelope-from fredrik.widlund@qbrick.com) Received: from localhost (localhost [127.0.0.1]) by mail.qbrick.com (Postfix) with ESMTP id 63B88519CE; Thu, 2 Nov 2006 16:53:59 +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 71842-02-4; Thu, 2 Nov 2006 16:53:58 +0100 (CET) Received: from [10.43.0.2] (fkwd0.p0.u3.local [10.43.0.2]) by mail.qbrick.com (Postfix) with ESMTP id F1D7D519CC; Thu, 2 Nov 2006 16:53:57 +0100 (CET) Message-ID: <454A14BF.2020800@qbrick.com> Date: Thu, 02 Nov 2006 16:54:39 +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> <454A0E86.6080906@qbrick.com> <454A0F68.7030809@samsco.org> In-Reply-To: <454A0F68.7030809@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:55:07 -0000 Yes I received it, and no I'm not saying it's a driver bug. However I did assume this would be the driver specific. Do I understand you correctly; you're saying that it's FreeBSD's controller I/O framework in general that cause this performance gap to Windows and Linux, and it's not driver specific? Kind regards, Fredrik Widlund Scott Long wrote: > 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" >>> >> > > _______________________________________________ > 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"