From owner-freebsd-current@FreeBSD.ORG Wed May 21 01:30:42 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD34A37B401 for ; Wed, 21 May 2003 01:30:42 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0325643F93 for ; Wed, 21 May 2003 01:30:42 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h4L8UeqN005082; Wed, 21 May 2003 01:30:41 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h4L8Ue06005081; Wed, 21 May 2003 01:30:40 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 21 May 2003 01:30:40 -0700 From: David Schultz To: Terry Lambert Message-ID: <20030521083040.GA5053@HAL9000.homeunix.com> Mail-Followup-To: Terry Lambert , Bruce Evans , Jun Kuriyama , Current References: <7m4r3onc7i.wl@black.imgsrc.co.jp> <20030521163526.I30051@gamplex.bde.org> <20030521075709.GB4783@HAL9000.homeunix.com> <3ECB3650.84333A13@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECB3650.84333A13@mindspring.com> cc: Jun Kuriyama cc: Current Subject: Re: panic: mount: lost mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 08:30:43 -0000 On Wed, May 21, 2003, Terry Lambert wrote: > David Schultz wrote: > > On Wed, May 21, 2003, Bruce Evans wrote: > > > Unfortunately, this is fairly normal file system behaviour when a critical > > > block is unreadable or damaged. Here vfs detects a problem that it knows > > > it cannot handle, and panics. > > > > I've run into this as well while testing other properties of how > > removable media is handled. Is there an easy way to get slightly > > more graceful behavior, such as forcing a downgrade to r/o and > > zapping the vnodes for any unrecoverable files a la 'umount -f'? > > Not if you have outstanding dirty buffers. The best you can > do is demand they put the disk back and say dumb things like > "Abort, Retry, Ignore?" on the console [...] Just in case you're not entirely kidding here, forcing a r/o downgrade allows you to invalidate all the dirty buffers, so you don't have to worry about causing the filesystem to become more inconsistent than it already is. > I'm also pretty sure that if you checked your data everywhere > you would have to to catch things like media change events (as > opposed to just media removal) or, as you suggest, out of range > data, then you would be spending all your time validating your > data, rather than doing real work. Media change detection is a separate issue for removable media. I tend to regard it as somewhat less important than handling medium errors, because anyone who changes disks out from under the operating system deserves whatever he gets. ;-)