From owner-freebsd-hackers Wed May 30 3:59:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id 41AE937B423 for ; Wed, 30 May 2001 03:59:41 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.3.Dial1.SanJose1.Level3.net [209.245.139.3]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id GAA19828; Wed, 30 May 2001 06:59:33 -0400 (EDT) Message-ID: <3B14D2AF.47CD9ECB@mindspring.com> Date: Wed, 30 May 2001 03:59:59 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Terry Lambert , hackers@freebsd.org Subject: Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE References: <20010527214531.R65666-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Mike Silbersack wrote: > 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?) Apparently IBM has finally released an IDE drive that can do tagged command queueing, and it's in -current, if the drive supports 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". Not really; I avoid IDE drives for important systems. 8-). The other joke is that write caching is always enabled, as shipped from the manufacturer, so that they can compete on benchmarks with other manufacturers. It only helps to encourage this behaviour that IDE drives, until the IBM drive, could not interleave I/O, so the only way around serializing at the disk interface was write-caching and lying to the OS about the data having been committed to stable storage, when it wasn't. > Clearly, write caching makes some drives (probably those > which come with it enabled) much faster. I.e.: all of them. > Also clearly, write caching hasn't caused many problems, > since we would have seen reports by now if it was happening. That assumes that they attribute the problems reported by fsck to the correct culprit, or not. I rather expect that most people with important servers go with SCSI disks, like they always have in the past. > 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." You need to look at the code; it would be relatively hard to make this runtime tunable instead of boot-time tunable. > 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. I think the answer is "reliable by default". As a friend of mine says "I can make it go as fast as you want, if it doesn't have to work"... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message