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>