From owner-freebsd-fs  Wed Sep 20  0: 4:12 2000
Delivered-To: freebsd-fs@freebsd.org
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
	by hub.freebsd.org (Postfix) with ESMTP
	id AA4E637B424; Wed, 20 Sep 2000 00:04:10 -0700 (PDT)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.9.3/8.9.3) id AAA14533;
	Wed, 20 Sep 2000 00:02:47 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp03.primenet.com, id smtpdAAA5laqvC; Wed Sep 20 00:02:39 2000
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id AAA00154;
	Wed, 20 Sep 2000 00:03:59 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <200009200703.AAA00154@usr05.primenet.com>
Subject: Re: disable write caching with softupdates?
To: archie@whistle.com (Archie Cobbs)
Date: Wed, 20 Sep 2000 07:03:59 +0000 (GMT)
Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG
In-Reply-To: <200009200030.RAA08442@bubba.whistle.com> from "Archie Cobbs" at Sep 19, 2000 05:30:06 PM
X-Mailer: ELM [version 2.5 PL2]
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

> Isn't it safer (in the face of a power failure) to disable write
> caching on a hard disk when softupdates is in use?

Yes.  You _must_ guarantee that the drive does not complete
writes out of sequence that it reports having completed in
sequence.  Hardware which lies is evil.


> The ata driver currenly always enables write caching. Perhaps
> there should be a sysctl knob to turn it on/off?

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.

The only exception would bit if, like NetApp boxes, PrestoServ,
and similar systems, your writes were intention logged to
NVRAM before being scheduled.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


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