Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jan 2013 17:46:14 -0800 (PST)
From:      Don Lewis <truckman@FreeBSD.org>
To:        se@FreeBSD.org
Cc:        fodillemlinkarim@gmail.com, freebsd-hackers@FreeBSD.org, gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org
Subject:   Re: IBM blade server abysmal disk write performances
Message-ID:  <201301200146.r0K1kFxY019796@gw.catspoiler.org>
In-Reply-To: <50FABB71.6050406@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Jan, Stefan Esser wrote:
 
> 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).

For a very long time, all of the SCSI drives that I have purchased have
come with the WCE bit turned on.  I always had to remember to use
camcontrol to turn it off.  When I last benchmarked it quite a few years
ago, buildworld times were about the same with either setting, and my
filesystems were a lot safer with WCE off, which UFS+SU depends on. I've
also seen drives dynamically drop the number of supported tags WCE was
on and the write cache started getting full, which made CAM unhappy.

I've been using SCSI for anything important for all these years except
on my laptop.  I haven't yet switched to SATA because I haven't put
together a new system since NCQ support made it into -STABLE.  The hard
drives in my -CURRENT machine are cast-offs from my primary machine.
Just doin' my part to make sure legacy support isn't broken ...





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301200146.r0K1kFxY019796>