From owner-freebsd-fs  Thu Sep 21  1:24:13 2000
Delivered-To: freebsd-fs@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP
	id B16BE37B50D; Thu, 21 Sep 2000 01:24:07 -0700 (PDT)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id KAA98478;
	Thu, 21 Sep 2000 10:25:00 +0200 (CEST)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200009210825.KAA98478@freebsd.dk>
Subject: Re: disable write caching with softupdates?
In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1C9@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 20, 2000 07:24:44 am"
To: Stephen.Byan@quantum.com (Stephen Byan)
Date: Thu, 21 Sep 2000 10:25:00 +0200 (CEST)
Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG,
	freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org')
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

It seems Stephen Byan wrote:
> > 
> > Write caching should _never_ be enabled, unless you don't
> > care about the data, or the drive reports the operation
> > queueing and completion seperately, so that the OS knows
> > the completion order; even then, the OS will have to be
> > prepared to stall writing new data until completion has
> > occurred at any given synchronizatin point, so that it is
> > impossible for the drive to complete the requests out of
> > the order permitted by the OS.
> > 
> > With regard to "_never_": even a sync mounted FS will not
> > be recoverable to a deterministic state if write caching
> > does not guarantee completion in FIFO order, for obvious
> > reasons -- it doesn't matter if you go async in the kernel,
> > or async in the drive, either way your data gets screwed.
> 
> Wouldn't it be acceptable to mark the meta-data writes as non-cacheable
> (i.e. write though to the media before signalling completion), and let the
> remaining writes (user data writes) be cacheable? I think this would improve
> the performance of the file system.
> 
> SCSI has supported this for years, in the form of the FUA bit in the CDB for
> the write command. Somewhat similar behavior can be had in the newer flavors
> of ATA by issuing a "flush cache" command after each meta-data write, and
> waiting until the flush command completes before signalling the completion
> of the non-cacheable write.

OK, I played a bit with that, the only info I can see I get from the
higher levels is the BIO_ORDERED bit, so I tried to flush the cache
each time I get one of those, _bad_ idea, 10% performance loss...

Suggestions are welcome :)

-Søren


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