IBM blade server abysmal disk write performances

[Scott Long]

----- Original Message -----

> From: Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl>
> To: Scott Long <scott4long at yahoo.com>
> Cc: Dieter BSD <dieterbsd at gmail.com>; "freebsd-hackers at freebsd.org" <freebsd-hackers at freebsd.org>; "gibbs at FreeBSD.org" <gibbs at freebsd.org>; "scottl at FreeBSD.org" <scottl at freebsd.org>; "mjacob at FreeBSD.org" <mjacob at freebsd.org>
> Sent: Friday, January 18, 2013 11:10 AM
> Subject: Re: IBM blade server abysmal disk write performances
> 
>> 
>>  The default value, -1, instructs the driver to leave the STA drives at 
> their configuration default.  Often times this means that the MPT BIOS will turn 
> off the write cache on every system boot sequence.  IT DOES THIS FOR A GOOD 
> REASON!  An enabled write cache is counter to data reliability.  Yes, it helps 
> make benchmarks look really good, and it's acceptable if your data can be 
> safely thrown away (for example, you're just caching from a slower source, 
> and the cache can be rebuilt if it gets corrupted).  And yes, Linux has many 
> tricks to make this benchmark look really good.  The tricks range from buffering 
> the raw device to having 'dd' recognize the requested task and 
> short-circuit the process of going to /dev/null or pulling from /dev/zero.  I 
> can't tell you how bogus these tests are and how completely irrelevant they 
> are in predicting actual workload performance.  But, I'm not going to stop 
> anyone from trying, so give the above tunable a try
>>  and let me know how it works.
>> 
> If computer have UPS then write caching is fine. even if FreeBSD crash, 
> disk would write data
> 

I suspect that I'm encountering situations right now at netflix where this advice is not true.  I have drives that are seeing intermittent errors, then being forced into reset after a timeout, and then coming back up with filesystem problems.  It's only a suspicion at this point, not a confirmed case.

Scott