SAS Raid - mfi driver

Scott Long scottl at
Thu Nov 2 16:00:13 UTC 2006

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.


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?
>>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
>>>>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
>>>>cards, you should just add in the cost of the battery as a
>>>>matter-of-fact and not try to skimp by without one.
>>>>Fredrik Widlund wrote:
>>>>>Because the card itself will deal with the buffered writes
>>>>>of the kernel activity the risk should be less than using softupdates.
>>>>>Words like "screwed" seems to me to be exaggerated in the generic
>>>>>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
>>>>>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
>>>>>storage still is interesting to me, so if you could elaborate here
>>>>>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
>>>>>>I don't see how it could be *less* dangerous than using softupdates.
>>>>>>loss of power while writing and it seems to me that you are going
>>>>>>to be
>>>>>>screwed w/o a BBU.
>>>>>freebsd-stable at mailing list
>>>>>To unsubscribe, send any mail to
>>>>>"freebsd-stable-unsubscribe at"
>>freebsd-stable at mailing list
>>To unsubscribe, send any mail to "freebsd-stable-unsubscribe at"

More information about the freebsd-stable mailing list