Date: Thu, 02 Nov 2006 08:31:52 -0700 From: Scott Long <scottl@samsco.org> To: Fredrik Widlund <fredrik.widlund@qbrick.com> Cc: freebsd-stable@freebsd.org Subject: Re: SAS Raid - mfi driver Message-ID: <454A0F68.7030809@samsco.org> In-Reply-To: <454A0E86.6080906@qbrick.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454A0F68.7030809>