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

[Karl Denninger]

On 7/12/2016 09:22, Lowell Gilbert wrote:
> 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...
> _______________________________________________
You don't.  If you wind up detaching something with open RSS pages (or
worse, page file pages) you're going to take a panic.  So what?  You're
no worse off than you are with what is done now.


-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20160712/30c77a20/attachment.bin>