I'm forwarding the previous relevant e-mail for record:

Chuck Silvers wrote:
> 
> On Tue, Nov 23, 1999 at 01:47:42PM +0100, Manuel Bouyer wrote:
> > On Mon, Nov 22, 1999 at 11:08:40PM -0800, Chuck Silvers wrote:
> > > this one shouldn't be able to crash the system, ie. the kernel
> > > should be able to deal with any bad data on disk.  it may end up
> > > needing to disable access to the filesystem if the corruption is
> > > bad enough, but it should
> > > never crash.  the explicit panics that are in various filesystem now
> > > are just laziness.
> >
> > I disagree. In most case filesystem corruptions appear either because
> > of a kernel bug or defective hardware, and in such a case I *want*
> > the kernel to stop to do bad things. These checks are usefull.
> > For now, a fs corruption because of pilot error happened for me
> > only one time, and even this time I found the panic usefull.
> 
> yes, having the kernel stop doing bad things is exactly what you want,
> but taking out the whole machine just because one disk is flaking out
> is overkill.  it should suffice to simply disable access to that
> filesystem but otherwise allow the machine to continue operating
> normally.
> this is what various commercial filesystems do, and customers seem to be
> happy with this policy.  the assumption here is that the corruption
> is caused by failing hardware and not by a kernel bug, which should be
> the more common case if we're doing a good job when working on the code.
> 
> if you'd like to discuss this further, let's do it on tech-kern or
> in private mail.

I agree wholeheartily. The filesystem should not panic the machine,
dropping into DDB is about maximum what I'd take as "feasible".
IIRC someone also said that the panic might be optional
only if the user who mounted the fs is root (to avoid DoS attack).
That might be the first step.

Jaromir