SAS Raid - mfi driver

[Scott Long]

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"
>>
>