Skip site navigation (1)Skip section navigation (2)
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>