Re: panic: mount: lost mount

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 from a modal kernel
prompt that kills all other processing on the box until you
pay attention to it.  And that only works on 3.5" floppies,
not 5.25" floppies, because they didn't have the ability to
sense the difference between bad media and no media.

That assumes you can tell the difference between the disk that
was there before, and the one that's there now.

PC floppy hardware is generally really stupid; even when they
have a media change line, they generally don't hook it up; or
they're smart, and make the eject a software controlled function,
rather than a mechanical one, but you can't buy one of these for
a PC unless it's an Amiga or a Macintosh or a SPARC box.

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.

FWIW, most UNIX machines panic when you SPAM their FS out from
under them; Solaris boxes all do the same thing, if you give
them a corrupted MS-DOS disk to read (SunOS 4.x, SunOS 5.x).

-- Terry