From owner-freebsd-fs  Thu Sep 21  7:37:16 2000
Delivered-To: freebsd-fs@freebsd.org
Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137])
	by hub.freebsd.org (Postfix) with ESMTP
	id A827E37B424; Thu, 21 Sep 2000 07:37:09 -0700 (PDT)
Received: (from gibbs@localhost)
	by pluto.plutotech.com (8.9.2/8.9.1) id IAA36298;
	Thu, 21 Sep 2000 08:35:48 -0600 (MDT)
	(envelope-from gibbs)
From: Justin Gibbs <gibbs@plutotech.com>
Message-Id: <200009211435.IAA36298@pluto.plutotech.com>
Subject: Re: disable write caching with softupdates?
In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 21, 2000  6:40:24 am"
To: Stephen.Byan@quantum.com (Stephen Byan)
Date: Thu, 21 Sep 2000 08:35:48 -0600 (MDT)
Cc: mbendiks@eunet.no, Stephen.Byan@quantum.com, fs@FreeBSD.ORG,
	sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Without write caching, you pay one disk rotation for each sequential write.

This should not be the case if you are allowed to overlap commands.  The
only penalty should be increased latency in seeing a write complete.

Because ATA and now even some SCSI drives only support the "basic queuing"
feature set (cannot specify an ordered write barrier to the device), we'll
have to find some way to give ordered semantics on these devices or just
abandon the use of the B_ORDERED buffer flag.  Softupdates does not
use it, but FFS does in a few places.  Too bad... back when I added it
all SCSI devices that supported tagged queuing made this easy to do
and I expected to see ATA follow SCSI's lead and implement the same
primitive.

--
Justin


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message