From owner-freebsd-hackers  Thu Feb 20 03:01:00 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id DAA05859
          for hackers-outgoing; Thu, 20 Feb 1997 03:01:00 -0800 (PST)
Received: from hda.hda.com (ip41-max1-fitch.ziplink.net [199.232.245.41])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA05853
          for <hackers@FreeBSD.org>; Thu, 20 Feb 1997 03:00:56 -0800 (PST)
Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id FAA02640; Thu, 20 Feb 1997 05:55:08 -0500
From: Peter Dufault <dufault@hda.com>
Message-Id: <199702201055.FAA02640@hda.hda.com>
Subject: Re: drive write caches
In-Reply-To: <199702200052.QAA00662@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Feb 19, 97 04:52:38 pm"
To: asami@vader.cs.berkeley.edu (Satoshi Asami)
Date: Thu, 20 Feb 1997 05:55:07 -0500 (EST)
Cc: joerg_wunsch@uriah.heep.sax.de, james@wgold.demon.co.uk,
        hackers@FreeBSD.org, dufault@hda.com
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>  * >  - if the OS tells me it has a successful write through the
>  * >    disk device, can I rely on:
>  * > 
>  * >    a) the data is on the platter
>  * 
>  * It is.  Since physio(9) waits for the completion, you should be
>  * notified of any lower-level errors.  Note that this is _unlike_ with
>  * the block devices, where writing happens asynchronously, so the kernel
>  * did already declare the write operation as successful by the time it
>  * notices an error.
> 
> Really?  I think drives have their own cache, and if they have write
> buffering turned on, they will happily return "write complete" when
> they are only holding data in the buffer.

This is the deferred error that you can get a system console message
about - it means there was an error for a transfer that already
returned a successful completion.  I believe the way to handle this properly
is to issue a SYNCHRONIZE CACHE command at the right place and then
handle any deferred errors that come back as a result.  This
would require putting a hook in the file system code someplace
to do that sync / fixup.

The page to turn it off is the caching page (page 8):

# Caching page:
0x08 {
	{Reserved} *t5
	{WCE} t1
	{MF} t1
	{RCD} t1
	{Demand Retention Priority} t4
	{Write Retention Priority} t4
	{Disable Pre-fetch Transfer Length} i2
	{Minumum Pre-fetch} i2
	{Maximum Pre-fetch} i2
	{Maximum Pre-fetch Ceiling} i2
}

WCE is write cache enable.  I've just checked and two of my disks
(from Rodney, Rod, if you're out there) have the write cache disabled.

Peter

-- 
Peter Dufault (dufault@hda.com)   Realtime Machine Control and Simulation
HD Associates, Inc.               Voice: 508 433 6936