From owner-freebsd-stable Sat May 5 11:30:18 2001 Delivered-To: freebsd-stable@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id BA3A237B43C for ; Sat, 5 May 2001 11:30:15 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f45ITdC49030; Sat, 5 May 2001 11:29:39 -0700 (PDT) (envelope-from dillon) Date: Sat, 5 May 2001 11:29:39 -0700 (PDT) From: Matt Dillon Message-Id: <200105051829.f45ITdC49030@earth.backplane.com> To: Doug Russell Cc: freebsd-stable Subject: Re: soft update should be default References: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Of course as Gordon writes above, all bets are off if your disk does :> write-caching. : :I still don't totally understand this. In the case of a drive with WCE, :aren't we always assuming that the drive will correctly write the data out :eventually, even if the system crashes? : :This assumes that we aren't talking about a power failure, here, but if it :is an external drive array with dual power supplies, at least one battery :backed, it doesn't matter even if the compuer power is cut, the drive :should still eventually flush out it's cache, shouldn't it? : :(Ideal world, of course, I know.... What if the SCSI bus wedges a drive?) : :> There is an excellent paper entitled, Soft Updates: A Solution to the :> Metadata Update Problem in File Systems, by Gergory R. Granger and Yale :> N. Patt at EECS, University of Michigan. The paper is at :> http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/. : :Sounds interesting... I'm going to have to go take a look.... : :Later....... Not only will the hard drive not be able to write the write-cached data to the media, but IDE hard drives will not guarentee write ordering either. Someone did a test a while back and found that under heavy disk loads an IDE drive could hold some of the dirty data in its cache for an indefinite period of time without writing it out. i.e. it would write out some of the dirty data but also hold some of it indefinitely, unwritten. So turning on WCE is playing with fire. WCE was mangled because the drive manufacturers were more interested in posting high transfer rate numbers for benchmarks then in keeping people's data safe. I remember when it happened... the day the drive manufacturers started using their lobotomized SCSI cores internally was the day they realized they could cache writes. Now, there is an IDE flush command. Theoretically it would be possible to write out non-conflicting sectors with WCE turned on, then flush the cache, and repeat. Theoretically it would be possible for a RAID system with its own battery backed cache to operate with WCE turned on and flush the disks before the data would be lost from its own cache. Realistically, drive manufacturers rarely test the command set the drives are supposed to support beyond making sure it works with some idiotic windows driver, so these cool commands are as likely to crash the drive then to work as advertised. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message