Re: panic: mount: lost mount

David Schultz wrote:
> On Wed, May 21, 2003, Terry Lambert wrote:
> > David Schultz wrote:
> > 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.

So does panic'ing, and it doesn't have the disadvantage of you
continuing running with inconsistent data.  8-).

Actually, you're wrong here: flushing the dirty buffers is what
permits you to perform a read-only downgrade.


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

It's not like these errors magically appeared on the disk while
it was in operation, such that sector sparing could be invoked,
if they were in the normal write path, or the read/write errors
could be detected in the course of normal operations at the
point that they occurred -- code which is prepared to handle a
contingency like that, BTW -- rather than when the FS went to use
the data.

Anyone who uses a corrupt disk without fsck'ing it first also
deserves what they get.  Writing a working fsck for all the FS's
supported by FreeBSD is left as an exercise for the student.

8-).

-- Terry