From owner-freebsd-hackers@FreeBSD.ORG  Sun Jan 20 01:46:26 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@FreeBSD.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id B0D404F7;
 Sun, 20 Jan 2013 01:46:26 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242])
 by mx1.freebsd.org (Postfix) with ESMTP id 957329A8;
 Sun, 20 Jan 2013 01:46:26 +0000 (UTC)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
 by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r0K1kFxY019796;
 Sat, 19 Jan 2013 17:46:19 -0800 (PST)
 (envelope-from truckman@FreeBSD.org)
Message-Id: <201301200146.r0K1kFxY019796@gw.catspoiler.org>
Date: Sat, 19 Jan 2013 17:46:14 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: IBM blade server abysmal disk write performances
To: se@FreeBSD.org
In-Reply-To: <50FABB71.6050406@freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Cc: fodillemlinkarim@gmail.com, freebsd-hackers@FreeBSD.org, gibbs@FreeBSD.org,
 scottl@FreeBSD.org, mjacob@FreeBSD.org
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jan 2013 01:46:26 -0000

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 ...