Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 May 2001 22:30:09 -0500 (CDT)
From:      Mike Silbersack <silby@silby.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        <hackers@freebsd.org>
Subject:   Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
Message-ID:  <20010527214531.R65666-100000@achilles.silby.com>
In-Reply-To: <200105252059.NAA13350@usr06.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 25 May 2001, Terry Lambert wrote:

> So add an option to sysinstall called:
>
> 	"Fast and at least as reliable as Linux"
>
> and let them find out for themselves that that means that it's
> really dangerous, and that after a crash for whatever reason (e.g.
> your panic crash, or a power failure for anyone without a UPS in
> California), they will have to manuall fsck, whereas without the
> write caching, it wouldn't have been a problem.

Ok, I've had some time to look through some other discussions on this
issue, and ready to jump back in. :)

First, ignore my comment about the manual fsck on current w/softupdates.
Someone on -current just reported the same problem; it sounds like a newly
added bug to current, which probably doesn't affect stable.

As to technical arguments for enabling write caching under uncertain power
conditions, I can't come up with any.  (Until the BIO_ORDERED work is
done; is anyone actually working on it?)

The demonization of linux above is unwarranted; I checked the linux ata
driver, and they don't touch the write cache setting at all; it's left at
the default setting for the drive.  FreeBSD, on the other hand, will
always set the write cache status so that it's at a known value.  In
releases prior to 4.3, it was being set to enabled.  Hence, you should be
saying "Fast and at least as reliable as FreeBSD 4.0, 4.1, and 4.2".

Clearly, write caching makes some drives (probably those which come with
it enabled) much faster.  Also clearly, write caching hasn't caused many
problems, since we would have seen reports by now if it was happening.

There seem to be two compromises which could be made:

1.  Have the ata driver leave the write cache setting alone by default,
providing a sysctl which can cause disabled or enabled if requested.  When
the default is allowed, put something in dmesg which says "Note: Write
caching may be enabled.  See ata(4) for the reliability implications of
this."

2.  Leave the default to be 0, but instead print "Please see ata(4) to
choose your write cache preferences."  Also, put something in the release
notes or src/updating which mentions this.

Note that in either case it's note FreeBSD's "fault" that write caching is
enabled; it's the user's or the drive maker's.

Mike "Silby" Silbersack


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010527214531.R65666-100000>