From owner-cvs-all  Mon Sep 20 12:30:41 1999
Delivered-To: cvs-all@freebsd.org
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9389D14E1D; Mon, 20 Sep 1999 12:30:37 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from semuta.feral.com (semuta [192.67.166.70])
	by feral.com (8.8.7/8.8.7) with ESMTP id MAA03859;
	Mon, 20 Sep 1999 12:28:53 -0700
Date: Mon, 20 Sep 1999 12:30:28 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: Bruce Evans <bde@zeta.org.au>
Cc: "Justin T. Gibbs" <gibbs@caspian.plutotech.com>,
	Matt Dillon <dillon@FreeBSD.org>, cvs-committers@FreeBSD.org,
	cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern vfs_bio.c 
In-Reply-To: <Pine.BSF.4.10.9909210449080.47853-100000@alphplex.bde.org>
Message-ID: <Pine.BSF.4.05.9909201229050.44336-100000@semuta.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

> > 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.


FWIW, I agree with this. Just as long as any buffers for this device are
destroyed. Devices can come and go, but generation numbers for devices
don't get propagated back to the buffer cache.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message