From owner-cvs-all Mon Sep 20 12:26:34 1999 Delivered-To: cvs-all@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id D3D10154E7 for ; Mon, 20 Sep 1999 12:26:27 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 7126 invoked from network); 20 Sep 1999 19:26:22 -0000 Received: from d161.syd2.zeta.org.au (203.26.9.33) by gidora.zeta.org.au with SMTP; 20 Sep 1999 19:26:22 -0000 Date: Tue, 21 Sep 1999 05:26:16 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: "Justin T. Gibbs" Cc: Matt Dillon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_bio.c In-Reply-To: <199909201734.LAA00382@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Mon, 20 Sep 1999, Justin T. Gibbs wrote: > >dillon 1999/09/20 09:19:24 PDT > > > > Modified files: > > sys/kern vfs_bio.c > > Log: > > Fix bug in brelse() regarding redirtying buffers on B_ERROR. brelse() > > improperly ignored the B_INVAL flag when acting on the B_ERROR. > > If both B_INVAL and B_ERROR are set the buffer is typically out of the > > underlying device's block range and must be destroyed. If only B_ERROR > > is set (for a write), a write error occured and operation remains as it > > was before: the buffer must be redirtied to avoid corrupting the > > filesystem state. > > If a device "goes away", how should any pending buffers be marked? Does a > umount -f cause pending buffers to be B_INVAl'ed? I'm pretty sure that > we still can't rid the system of the knowledge of a mounted fs for a device > that has disappeared, but I haven't checked recently. I think they should set B_ERROR in bp->b_flags and set bp->b_error to something other than EIO (ENXIO perhaps), and brelse() should only retry writes when bp->b_error == EIO. I/o beyond EOF is already handled in this way in drivers ("something other than EIO" is EINVAL). No device drivers set B_INVAL directly now; the above fix is apparently for nfs. umount -f doesn't cause buffers to be B_INVAL'ed. Writing of unwritable buffers is retired endlessly. umount -f simply forces a write, and in the best case, unmount(2) fails when the forced write fails. For some filesystems, the write error is ignored and the unwritable buffer causes a panic after unmount() blunders on. A fixed umount -f would invalidate the buffers, perhaps after retrying a couple of times. However, unmount() is really too late. Unwritable buffers can currently sit in the buffer cache for as long as the system is up, causeing i/o on every sync. They should be discarded after a few retries. I think umount -f once handled gone-away devices as well as possible (by forgetting about their buffers). unmount() begins by flushing all the buffers. Unwritable buffers used to be discarded immediately by brelse(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message