Date: Mon, 14 May 2001 09:35:53 +0200 (CEST) From: Søren Schmidt <sos@freebsd.dk> To: Kevin Oberman <oberman@es.net> Cc: Mike Smith <msmith@FreeBSD.ORG>, Leon Breedt <ljb@devco.net>, freebsd-mobile@FreeBSD.ORG Subject: Re: slow IDE performance Message-ID: <200105140735.f4E7Zso17545@freebsd.dk> In-Reply-To: <200105111639.f4BGd6c03347@ptavv.es.net> "from Kevin Oberman at May 11, 2001 09:39:06 am"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Kevin Oberman wrote: > The consensus of the experts (including Soren Schmidt, author of the > ATA driver,) after the referenced thread was that there were serious > problems with the write cache implementation on may IDE disks that > made write cache use "dangerous at any speed". Not just with soft > updates, but with normal synchronous disk operation. Hmm, maybe its time for me to chime in here... The only problem with write cache is that you can potentially loose uptil a cache full of data if the power goes away unexpectedly. This is especially bad if you use softupdates, but harmfull on all filesystems of cause. Without WC you should only loose the last sector that is about to be written or actively being written when power goes away, which can still be bad, but more limitted in scope. Now, that aside, it is also a fact that lots of modern disks takes a significant performance hit when WC is disabled, the worst example so far are some of the newer Maxtors, they drop to < 8MB/s write speed in that case. > Since Windows does not make use of many ATA functions used to make > cache fairly safe for SCSI and often does not ever write any data from > cache to disk in a power failure, the correct operation of the cache > flush operation is critical, but I have been told that it simply does > not work with many disks. Well, I dont know where you heard that, but the flush cache command has worked on all the ATA disks I've seen so far... The problem at hand is only related to using an on-disk cache, the reason is that the system _thinks_ it has written data to the media, and that is not nessesarily the case when WC is enabled, and since softupdates relies on that info, well.... We are looking at ways to try to do a flush of the disk cache in the right places, but so far we have no working setup. Now I've done some serious testing here on this problem, using an "automated power outage gadget" and the results so far tells me the problem with just using WC is existant, but it has not corrupted data any worse than without (data sample is > 500 powercuts with/without WC on). One interesting thing is that using IBM disks and utilising tagged queueing seems to work as expected, the disk apparently first reports a write done when the data has actually hit the media, or I've just been lucky about well over 500 times there also :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105140735.f4E7Zso17545>