Date: Thu, 02 Nov 2006 16:54:39 +0100 From: Fredrik Widlund <fredrik.widlund@qbrick.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-stable@freebsd.org Subject: Re: SAS Raid - mfi driver Message-ID: <454A14BF.2020800@qbrick.com> In-Reply-To: <454A0F68.7030809@samsco.org> References: <45470D95.5020801@qbrick.com> <ei7448$4rs$1@sea.gmane.org> <454718DD.8060108@qbrick.com> <45471ACC.2030604@fer.hr> <4547421D.2010206@qbrick.com> <45477FCC.9050901@qbrick.com> <ei8hus$jec$1@sea.gmane.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454A14BF.2020800>