From owner-freebsd-fs@FreeBSD.ORG Fri May 21 09:53:53 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE2116A4EA for ; Fri, 21 May 2004 09:53:53 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F3643D1F for ; Fri, 21 May 2004 09:53:53 -0700 (PDT) (envelope-from garycor@comcast.net) Received: from comcast.net (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (sccrmhc11) with SMTP id <2004052116534001100qms84e> (Authid: garycor); Fri, 21 May 2004 16:53:41 +0000 Message-ID: <40AE34DA.6060804@comcast.net> Date: Fri, 21 May 2004 12:56:58 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Byan References: <20040517174836.GA983@frontfree.net> <40A974DA.30704@comcast.net> <200405201615.51539@misha-mx.virtual-estates.net> <7CE7075D-AB35-11D8-B0BF-000A957CD5B0@egenera.com> In-Reply-To: <7CE7075D-AB35-11D8-B0BF-000A957CD5B0@egenera.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org cc: Mikhail Teterin cc: Julian Elischer Subject: Re: QMail and SoftUpdates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 16:53:53 -0000 Steve Byan wrote: >> => Even if the OS crashes, as long as power is supplied to the drive, >> => its firmware should finish writing the data from its cache to the >> => disk media, no? And therefore, as long as one has a stable power >> => source, e.g. running off a UPS, there really isn't any great risk >> => from on-drive write caches, is there? >> = >> =No. Unlike SCSI disks, ATA disks will toss their write-cache on a >> =reset. When the system crashes and the BIOS starts rebooting, guess >> =what it issues to the ATA disks? Yep, a reset. > > I checked with my BIOS source, and I got this wrong. After a crash, the > BIOS is usually entered as a result of the crash-code (panic(), in the > case of *BSD) invoking a hard reset by writing to the reset bit of I/O > port 92. This causes a reset of the hardware, which includes the PCI bus > and the ATA disks as well as the CPU. I haven't crashed a FreeBSD box in quite a while :), but isn't there a 15 second (or more?) delay, after a panic, before the FreeBSD code auto-reboots (i.e. restarts the BIOS)? In which case I would expect the on-disk caches to have been flushed to the media before the BIOS gets control and resets things... >> So with ATA write-cache >> =enabled, your filesystem is likely to be toast after a crash, as well >> =as after a power failure. >> >> Is not this only of concern if the power is restored and the BIOS resets >> the disks _before_ they flush their write caches? I'd expect them to do >> that (the flushing) within seconds anyway, no? > > > I'm confused by your reference to the restoration of power in your > question. If you lose power to the whole system, then it's game over. > Are you suggesting that the disks might be powered separately from the > CPU and motherboard, and that the CPU might lose power and then regain > it while the disks are still powered? I don't know of any systems that > are designed that way. > > The primary case I was discussing was the case where the system has > power, but the OS crashes. Yes, if the disks manage to win the race by > flushing their write cache before the hard reset is issued by the crash > code, then everything is fine. However, the disks don't know that the > system is crashing; in general there's no flush command issued to the > disks. (I haven't looked at FreeBSD source, but comments on this list > made a few years back lead me to believe that panic() doesn't issue > flush cache commands to ATA disks.) I think the panic code quite soon > after getting control, and the disks flush their write cache rather > lazily, rather than eagerly. So if the ATA disks are getting a lot of > write traffic, it's likely that you will lose the race, and there will > be data in the write cache that has not made it to the media at the time > that the disk is reset.