Date: Wed, 21 May 2003 01:30:40 -0700 From: David Schultz <das@FreeBSD.ORG> To: Terry Lambert <tlambert2@mindspring.com> Cc: Current <freebsd-current@FreeBSD.ORG> Subject: Re: panic: mount: lost mount Message-ID: <20030521083040.GA5053@HAL9000.homeunix.com> In-Reply-To: <3ECB3650.84333A13@mindspring.com> References: <7m4r3onc7i.wl@black.imgsrc.co.jp> <20030521163526.I30051@gamplex.bde.org> <20030521075709.GB4783@HAL9000.homeunix.com> <3ECB3650.84333A13@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030521083040.GA5053>