Date: Sat, 19 Jan 2013 16:27:45 +0100 From: Stefan Esser <se@freebsd.org> To: Karim Fodil-Lemelin <fodillemlinkarim@gmail.com> Cc: freebsd-hackers@freebsd.org, gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org Subject: Re: IBM blade server abysmal disk write performances Message-ID: <50FABB71.6050406@freebsd.org> In-Reply-To: <50F9DB9A.9050303@gmail.com> References: <CAA3ZYrBV9f%2BcHx4jvS0UKTr%2Bp7eNUBA0S2%2Bv9oZAHqwm9VBOWw@mail.gmail.com> <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <alpine.BSF.2.00.1301182217590.1478@wojtek.tensor.gdynia.pl> <1358544287.32417.251.camel@revolution.hippie.lan> <50F9CFEB.5060302@feral.com> <50F9DB9A.9050303@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 19.01.2013 00:32, schrieb Karim Fodil-Lemelin:
> * Although no one has reported problems with the 2 gig
> * version of the DCAS drive, the assumption is that it
> * has the same problems as the 4 gig version. Therefore
> * this quirk entries disables tagged queueing for all
> * DCAS drives.
> */
> { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DCAS*", "*" },
> /*quirks*/0, /*mintags*/0, /*maxtags*/0
>
> So I looked at the kern/10398 pr and got some feeling of 'deja vu'
> although the original problem was on FreeBSD 3.1 so its most likely not
> that but I though I would mention it. The issue described is awfully
> familiar. Basically the SAS drive (scsi back then) is slow on writes but
> fast on reads with dd. Could be a coincidence or a ghost from the past
> who knows...
I remember those drives from some 20 years ago. Before that time, SCSI
and IDE drives were independently developed and SCSI drives offered way
better performance and reliability. But at about this time there were
SCSI and IDE drives that differed only in their interface electronics.
And from that time I and models I remember several SCSI quirks in IBM
drives (DCAS and DORS), often with regard to tagged commands.
I seem to remember, that drives of that time required the write cache
to be enabled to get any speed-up from tagged commands. This was no
risk with SCSI drives, since the cache did not make the drives lye
about command completion (i.e. the status for the write was only
returned when the cached data had been written to disk, independently
of the write cache enable).
Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50FABB71.6050406>