Date: Fri, 18 Jan 2013 09:22:58 -0800 (PST) From: Scott Long <scott4long@yahoo.com> To: Dieter BSD <dieterbsd@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: "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: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> In-Reply-To: <CAA3ZYrCgMmGi3EHKEuXb=qWPjC2zSMYcfgZ6nh-ipqQ7dAeVdA@mail.gmail.com> References: <CAA3ZYrCgMmGi3EHKEuXb=qWPjC2zSMYcfgZ6nh-ipqQ7dAeVdA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Try adding the following to /boot/loader.conf and reboot:=0A=0Ahw.mpt.enabl= e_sata_wc=3D1=0A=0AThe default value, -1, instructs the driver to leave the= STA drives at their configuration default. =A0Often times this means that = the MPT BIOS will turn off the write cache on every system boot sequence. = =A0IT DOES THIS FOR A GOOD REASON! =A0An enabled write cache is counter to = data reliability. =A0Yes, it helps make benchmarks look really good, and it= 's acceptable if your data can be safely thrown away (for example, you're j= ust caching from a slower source, and the cache can be rebuilt if it gets c= orrupted). =A0And yes, Linux has many tricks to make this benchmark look re= ally good. =A0The tricks range from buffering the raw device to having 'dd'= recognize the requested task and short-circuit the process of going to /de= v/null or pulling from /dev/zero. =A0I can't tell you how bogus these tests= are and how completely irrelevant they are in predicting actual workload p= erformance. =A0But, I'm not going to stop anyone from trying, so give the a= bove tunable a try and let me know how it works.=0A=0ABtw, I'm not subscribed to the hackers = mailing list, so please redistribute this email as needed.=0A=0AScott=0A=0A= =0A=0A=0A>________________________________=0A> From: Dieter BSD <dieterbsd@= gmail.com>=0A>To: freebsd-hackers@freebsd.org =0A>Cc: mjacob@FreeBSD.org; g= ibbs@FreeBSD.org; scottl@FreeBSD.org =0A>Sent: Thursday, January 17, 2013 9= :03 PM=0A>Subject: Re: IBM blade server abysmal disk write performances=0A>= =0A>> I am thinking that something fancy in that SAS drive is=0A>> not bei= ng handled correctly by the FreeBSD driver.=0A>=0A>I think so too, and I th= ink the something fancy is "tagged command queuing".=0A>The driver prints "= da0: Command Queueing enabled" and yet your SAS drive=0A>is only getting 1 = write per rev, and queuing should get you more than that.=0A>Your SATA driv= e is getting the expected performance, which means that NCQ=0A>must be work= ing.=0A>=0A>> Please let me know if there is anything you would like me to = run on the=0A>> BSD 9.1 system to help diagnose this issue?=0A>=0A>Looking = at the mpt driver, a verbose boot may give more info.=0A>Looks like you can= set a "debug" device hint, but I don't=0A>see any documentation on what to= set it to.=0A>=0A>I think it is time to ask the driver wizards why TCQ isn= 't working,=0A>so I'm cc-ing the authors listed on the mpt man page.=0A>=0A= >=0A>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358529778.71931.YahooMailNeo>