----- Original Message ----- > From: Wojciech Puchar <woj...@wojtek.tensor.gdynia.pl> > To: Scott Long <scott4l...@yahoo.com> > Cc: Dieter BSD <dieter...@gmail.com>; "freebsd-hackers@freebsd.org" > <freebsd-hackers@freebsd.org>; "gi...@freebsd.org" <gi...@freebsd.org>; > "sco...@freebsd.org" <sco...@freebsd.org>; "mja...@freebsd.org" > <mja...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
