Date: Fri, 18 Jan 2013 10:18:56 -0800 (PST) From: Scott Long <scott4long@yahoo.com> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Dieter BSD <dieterbsd@gmail.com>, "gibbs@FreeBSD.org" <gibbs@freebsd.org>, "scottl@FreeBSD.org" <scottl@freebsd.org>, "mjacob@FreeBSD.org" <mjacob@freebsd.org> Subject: Re: IBM blade server abysmal disk write performances Message-ID: <1358533136.41693.YahooMailNeo@web120302.mail.ne1.yahoo.com> In-Reply-To: <alpine.BSF.2.00.1301181909250.12638@wojtek.tensor.gdynia.pl> References: <CAA3ZYrCgMmGi3EHKEuXb=qWPjC2zSMYcfgZ6nh-ipqQ7dAeVdA@mail.gmail.com> <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> <alpine.BSF.2.00.1301181909250.12638@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=0A=0A> From: Wojciech Puchar <wojtek@wojtek.te= nsor.gdynia.pl>=0A> To: Scott Long <scott4long@yahoo.com>=0A> Cc: Dieter BS= D <dieterbsd@gmail.com>; "freebsd-hackers@freebsd.org" <freebsd-hackers@fre= ebsd.org>; "gibbs@FreeBSD.org" <gibbs@freebsd.org>; "scottl@FreeBSD.org" <s= cottl@freebsd.org>; "mjacob@FreeBSD.org" <mjacob@freebsd.org>=0A> Sent: Fri= day, January 18, 2013 11:10 AM=0A> Subject: Re: IBM blade server abysmal di= sk write performances=0A> =0A>> =0A>> The default value, -1, instructs the= driver to leave the STA drives at =0A> their configuration default. =A0Oft= en times this means that the MPT BIOS will turn =0A> off the write cache on= every system boot sequence. =A0IT DOES THIS FOR A GOOD =0A> REASON! =A0An = enabled write cache is counter to data reliability. =A0Yes, it helps =0A> m= ake benchmarks look really good, and it's acceptable if your data can be = =0A> safely thrown away (for example, you're just caching from a slower sou= rce, =0A> and the cache can be rebuilt if it gets corrupted). =A0And yes, L= inux has many =0A> tricks to make this benchmark look really good. =A0The t= ricks range from buffering =0A> the raw device to having 'dd' recognize the= requested task and =0A> short-circuit the process of going to /dev/null or= pulling from /dev/zero. =A0I =0A> can't tell you how bogus these tests are= and how completely irrelevant they =0A> are in predicting actual workload = performance. =A0But, I'm not going to stop =0A> anyone from trying, so give= the above tunable a try=0A>> and let me know how it works.=0A>> =0A> If c= omputer have UPS then write caching is fine. even if FreeBSD crash, =0A> di= sk would write data=0A> =0A=0AI suspect that I'm encountering situations ri= ght now at netflix where this advice is not true. =A0I have drives that are= seeing intermittent errors, then being forced into reset after a timeout, = and then coming back up with filesystem problems. =A0It's only a suspicion = at this point, not a confirmed case.=0A=0AScott=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358533136.41693.YahooMailNeo>