Date: Fri, 11 May 2001 09:39:06 -0700 From: "Kevin Oberman" <oberman@es.net> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Leon Breedt <ljb@devco.net>, freebsd-mobile@FreeBSD.ORG Subject: Re: slow IDE performance Message-ID: <200105111639.f4BGd6c03347@ptavv.es.net> In-Reply-To: Your message of "Fri, 11 May 2001 08:28:35 PDT." <200105111528.f4BFSZY01262@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 11 May 2001 08:28:35 -0700 > From: Mike Smith <msmith@FreeBSD.ORG> > Sender: owner-freebsd-mobile@FreeBSD.ORG > > > The reason that disk cache was disabled is that many IDE disks are junk > > and don't deal with cache properly in many respects. As a result, use > > of write cache is placing the integrity of disk data in doubt and can > > lead to disastrous failure in the event of unexpected power failure. > > This has nothing to do with "IDE disks being junk"; it has to do with > softupdates not dealing well with the situation where cached disk writes > aren't really completed. Mike, I'm sure that you know more about these issues than I do, but what you write here is very different from what others knowledgeable in ATA disks and FreeBSD. Note especially messages from Matt Dillon and Peter Wemm. I did get the wrong thread in my message, though. It was "Disk I/O problem in 4.3-BETA" and can be viewed at: http://www.geocrawler.com/mail/thread.php3?subject=Disk+I%2FO+problem+in+4.3-BETA&list=163 I think that this (rather long) thread addresses the issues in great detail and should, at very least, make you think carefully about turning on write cache. 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. 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. > > I see a 400% increase in the time required for some disk write > > operations with write cache disabled, so I bit the bullet and enabled > > it on my laptop. It does have a good battery backup, after all, but be > > sure that you understand the risks involved in the use of write cache > > on cheap disks. > > Again, this has nothing to do with "cheap disks". Agreed. I should have said "some disks" as many expensive disks have the same problems. > > It is VERY dangerous to use write cache on a desktop or server where > > there is no battery backup. > > Kind of like picking your nose; there's a very real danger of puncturing > the back of your nasal cavity and scooping out a large gob of brain with > a fingernail if you sneeze just right, but the chances of this actually > happening to you are pretty damn small. Sorry, but I think this is simply not true. Power failures happen and it's pretty unlikely that one will kill your system, but it's far too likely for me to want to take the chance. Having lost my system to a corrupt file system, I really don't like to take chances. (Regular backups are also a REALLY good idea.) I was flooded by messages saying I was wrong to suggest that write cache was reasonably safe on a system that was battery protected, like a laptop. This all took place on stable. Feel free to look at the archives (although some of the messages taking me to task for suggesting that write cache on a laptop was not unreasonable were sent directly to me and not posted to the list.) Soren did not change the default for write cache lightly as he is very aware of the performance hit. But it's your data and you can do as you wish. I prefer to keep write cache on on my laptop and turn it off on my desktop. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 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?200105111639.f4BGd6c03347>