----- Original Message ----- > From: Wojciech Puchar <[email protected]> > To: Scott Long <[email protected]> > Cc: Dieter BSD <[email protected]>; "[email protected]" > <[email protected]>; "[email protected]" <[email protected]>; > "[email protected]" <[email protected]>; "[email protected]" > <[email protected]> > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
