SAS Raid - mfi driver

[Fredrik Widlund]

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"