Date: Thu, 02 Nov 2006 08:59:26 -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: <454A15DE.2000200@samsco.org> In-Reply-To: <454A14BF.2020800@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> <454A0F68.7030809@samsco.org> <454A14BF.2020800@qbrick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Do your performance test on Linux using 32k or 64k i/o blocks, then do it on FreeBSD using the same. You'll seem similar performance between the two. Unless your application is bypassing the filesystem to do raw I/O that is larger than that, you won't see any benefit from the larger i/o sizes that Linux can do. Scott Fredrik Widlund wrote: > 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?454A15DE.2000200>