Date: Fri, 21 May 2004 12:56:58 -0400 From: Gary Corcoran <garycor@comcast.net> To: Steve Byan <smb@egenera.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: QMail and SoftUpdates Message-ID: <40AE34DA.6060804@comcast.net> In-Reply-To: <7CE7075D-AB35-11D8-B0BF-000A957CD5B0@egenera.com> References: <20040517174836.GA983@frontfree.net> <40A974DA.30704@comcast.net> <D4BFC35E-AA97-11D8-B0BF-000A957CD5B0@egenera.com> <200405201615.51539@misha-mx.virtual-estates.net> <7CE7075D-AB35-11D8-B0BF-000A957CD5B0@egenera.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40AE34DA.6060804>