Not-so stable if you take a CAM error....

[Lowell Gilbert]

Karl Denninger <karl at denninger.net> writes:

> Why not force-detach the volume that takes the error instead of a panic()?
>
> That would lead to a panic if the detached volume was the system volume
> (obviously) but for a data volume it would simply result in it being
> forcibly unmounted (and dirty, so if it's corrupt it will get caught
> when reattached.)
>
> It seems that the current paradigm of saying "screw you, panic the
> machine" violates the principle of least astonishment and is overly
> punitive vis-a-vis necessity.  Refusing further I/O because the volume
> may now have a corrupt filesystem appears to be facially reasonable, but
> that doesn't necessarily wind up being fatal the system itself -- it is
> if that's the system volume and is not covered by some sort of
> redundancy, obviously, but it's not in all cases.

How do you find the processes with pages mapped from the filesystem's
vnodes? UFS is *very* tightly tied to the VM system, and intentionally
so. Recall that "umount -f" isn't exactly safe...