Date: Wed, 30 May 2001 03:59:59 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Silbersack <silby@silby.com> Cc: Terry Lambert <tlambert@primenet.com>, hackers@freebsd.org Subject: Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE Message-ID: <3B14D2AF.47CD9ECB@mindspring.com> References: <20010527214531.R65666-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B14D2AF.47CD9ECB>