As der Mouse suggested putting checking data before using it would
probably slow down common operations. Isn't this disscussion mixing two
scenarios:

(1) an administrator have mounted a partition that he trust (example
/usr). Then he probably wouldn't want expensive checks, because if the
kernel crash accessing this partition then it's most likely caused by
media error (if it isn't a kernel bug :). As we have the same
problems for corrupted RAM, this is somehow acceptable.

(2) an non-root user mount a parition on an portable media. Maybe this
partition is marked clean but contains error and crash the kernel or even
worse execute arbitarty code. In this scenario an expensive check could be
acceptible.

This says if somebody puts in expensive checks, make them optional.
The need for expensive checks differs for different scenarios.

- Karl

On Wed, 15 Oct 2003, Robert Elz wrote:

> Date: Wed, 15 Oct 2003 04:06:48 +0700
> From: Robert Elz <kre@munnari.OZ.AU>
> To: Jason Thorpe <thorpej@wasabisystems.com>
> Cc: Greywolf <greywolf@starwolf.com>, tech-kern@NetBSD.org
> Subject: Re: Patch to disallow mounts of unclean FFS unless forced
>
>     Date:        Tue, 14 Oct 2003 13:54:30 -0700
>     From:        Jason Thorpe <thorpej@wasabisystems.com>
>     Message-ID:  <9B679C26-FE88-11D7-B507-000A957650EC@wasabisystems.com>
>
>   | Use the -f flag to force the mount.
>
> But that is root only - users are supposed (with the right sysctl setting)
> to be able to mount too.
>
>   | Right now, it's incredibly easy to accidentally mount an unclean file
>   | system that can cause the kernel to panic.  I'm trying to make it
>   | harder to have the accident happen.
>
> But isn't the right fix to make sure that the kernel correctly checks
> its data before using it?   And isn't NetBSD supposed to be all about
> doing the right fix, not just the expedient one?
>
> If by your proposed change you actually reduce the number of system panics,
> won't you theyeby be reducing the number of opportunities to encounter the
> underlying bugs that would cause those panics, and hence to get them fixed?
>
> Furthermore, the "clean" flag is just a bit in the filesystem, having it
> set guarantees nothing (though for sure in common cases it helps).
>
> kre
>
>