On 7/12/2016 09:22, Lowell Gilbert wrote: > Karl Denninger <k...@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 k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
