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... _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
