From owner-freebsd-hackers Mon Dec 15 01:11:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09618 for hackers-outgoing; Mon, 15 Dec 1997 01:11:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09613 for ; Mon, 15 Dec 1997 01:11:52 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id TAA00961; Mon, 15 Dec 1997 19:36:15 +1030 (CST) Message-Id: <199712150906.TAA00961@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mike Smith cc: Terry Lambert , bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Mon, 15 Dec 1997 18:12:06 +1030." <199712150742.SAA01554@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 19:36:13 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Consider a system running soft updates, in the face of a power failure, > > with a two block write crossing a cylinder boundry. This will result > > in a seek. All but the most modern drives (which can power track buffer > > writes and a seek through rotational energy of the disk) will fail to > > commit the write properly. > > Unfortunately, the above reasoning is soggy. In the face of a power > failure, there is no guarantee that a given block will be completely > updated, so the current "guaranteed atomicity" for single-block writes > doesn't exist. Oops. I'm the one who's wet here; I see the assumption now - block is not written, block is corrupt, block is written are all detectable states. This presumes there's no way for the device to present a block that's been only partially updated, which is reasonable. mike