Date: Fri, 01 Jun 2001 09:58:15 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Mike Silbersack <silby@silby.com>, Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG Subject: Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE Message-ID: <3B17C9A7.5A6535D2@mindspring.com> References: <20010527214531.R65666-100000@achilles.silby.com> <3B14D2AF.47CD9ECB@mindspring.com> <20010530050531.A64906@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > > 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. > > Until recently it *was* a sysctl. Wrong code. Look at the soft updates code. It is not happy about when you yank its assumptions out from under it. It is particularly not happy when it gets enabled with cached data for which it has not created dependencies, as it was formerly disabled. This can be fixed by flushing out all vnode data from an FS to disk, so that there is no cached data, and all the subsequent operations which have cached data thereafter have dependencies created whenever the data is cached. The primary problem with doing exactly this, and making soft updates a runtime tunable as a mount option, is that there is also the data associated with the device vnode on which the FS is mounted, which needs to be flushed (it only needs to be tracked via the dependencies of the FS data, since no data that has been modified will end up cached without a dependencicy). Doing that is a little harder, but not impossible (once soft updates is running, the data from the FS is write-through cached, so it can be correctly noted when it has been committed to stable storage). Now if you want the write caching on the drive to be a runtime tunable, what you need is to either: (1) Provide a "flush write cache" function in the driver, so that it can be flushed the same as the dirty vnode data. Then you need to get the disk to quit lying to the OS so that the in core dependency graph remains valid (currently, the only way to do this is to replace your IDE disks with SCSI disks, or to find one of the nonexistant IDE manufacturers whose drives support tagged command queues, AND whose drives do not lie, as with tagged command queues they do not need to, AND implement a cache-to-disk notification to the host). (2) Make the tunable turn off soft updates at the same time, since at that point you are effectively doing async I/O anyway. Turning off soft updates not at boot time has some other nasty ramifications; they are (mostly) already handled in the unmount code, however. Really, if you are going to run with IDE write cache enabled, you might as well mount sync. I'm actually not positive that this will actually cause the metadata to be written sync, or if it will continue to allow the IDE drive to lie to the OS about commits to stable storage, when it was really only a commit to the write cache. I'm also not positive about the switching mechanism between sync and async sufficiently to know that, if you switch to sync from async, and there is data in the write cache that is dirty, that it gets written immediately instead of orphaned; if orphaned, it may be impossible toswitch from async to sync, without a huge latency. If it orphans data, or can't support both sync and async operations simultaneously, well, then enabling write caching should imply an async mount, for all the good it is going to do you. -- 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?3B17C9A7.5A6535D2>