From owner-freebsd-hackers Sun May 27 20:30:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 8E3FE37B424 for ; Sun, 27 May 2001 20:30:10 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 65806 invoked by uid 1000); 28 May 2001 03:30:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 May 2001 03:30:09 -0000 Date: Sun, 27 May 2001 22:30:09 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: Subject: Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE In-Reply-To: <200105252059.NAA13350@usr06.primenet.com> Message-ID: <20010527214531.R65666-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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