SAS Raid - mfi driver

Scott Long scottl at samsco.org
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.

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 at freebsd.org mailing list
>>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>>>>To unsubscribe, send any mail to
>>>>>"freebsd-stable-unsubscribe at freebsd.org"
>>>>
>>_______________________________________________
>>freebsd-stable at freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> 
> 



More information about the freebsd-stable mailing list