From owner-freebsd-current@FreeBSD.ORG  Wed May 21 02:58:38 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 AC8DB37B401; Wed, 21 May 2003 02:58:38 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4D6CE43F3F; Wed, 21 May 2003 02:58:37 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id TAA13352;
	Wed, 21 May 2003 19:58:33 +1000
Date: Wed, 21 May 2003 19:58:32 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: David Schultz <das@FreeBSD.ORG>
In-Reply-To: <20030521075709.GB4783@HAL9000.homeunix.com>
Message-ID: <20030521194258.A39418@gamplex.bde.org>
References: <7m4r3onc7i.wl@black.imgsrc.co.jp>
	<20030521163526.I30051@gamplex.bde.org>
	<20030521075709.GB4783@HAL9000.homeunix.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: Jun Kuriyama <kuriyama@imgsrc.co.jp>
cc: Current <freebsd-current@FreeBSD.ORG>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2003 09:58:39 -0000

On Wed, 21 May 2003, David Schultz wrote:

> On Wed, May 21, 2003, Bruce Evans wrote:
> > On Wed, 21 May 2003, Jun Kuriyama wrote:
> >
> > > With today's current, I've got a panic with bad floppy.
> > >
> > > fd0: hard error cmd=read fsbn 57 of 56-63 (ST0 44<abnrml,top_head> ST1 20<bad_crc> ST2 20<bad_crc> cyl 1 hd 1 sec 4)
> > > panic: mount: lost mount
> > > cpuid = 1; lapic.id = 01000000
> > > Debugger("panic")
> > > Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
> > > db> trace
> > > Debugger(c03eb40e,1000000,c03f085e,ebc05b80,1) at Debugger+0x55
> > > panic(c03f085e,ebc05ba4,c03f0812,46a,c896b720) at panic+0x11f
> > > vfs_mount(c896b720,c7eafd40,c8a32b80,0,bfbfece0) at vfs_mount+0xa80
> > > mount(c896b720,ebc05d10,c0407bf6,3fb,4) at mount+0xb8
> > > syscall(2f,2f,2f,80a210f,bfbff6a4) at syscall+0x26e
> > > Xint0x80_syscall() at Xint0x80_syscall+0x1d
> >
> > 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'?

This particular error should be easy to recover from since it was
detected at a high level and is fairly simple.  It means that the file
system doesn't have a root inode.  mount() can just fail after doing
any necessary cleaning.  Hopefully not much cleaning is required.
OTOH, handling of vanishing of the root inode after mount() has succeeded
would require unsimple detection and cleaning.

Bruce