on 12/12/2012 23:58 John Baldwin said the following: > Hmmm, I'll have to chew on this. Adding lots of returns because panic's are > now no longer dead2 was why I ended up backing the removal of the > RESTARTABLE_PANICS option. > > I'm inclined to say that it's really bad to let a kernel known to be in a > bad state continue, and that if someone has asked for the slowdown of all > the extra checks INVARIANTS adds, they might as well minimize the chance for > data corruption by having the kernel stop as soon as a problem is detected. > > (Note that the primary reason I know for people not running with INVARIANTS > enabled is not that they don't want panics, but that they don't want the > performance hit.)
Previously we had two alternatives: - use INVARIANTS and be sure that the kernel is in sane state, that any bugs are caught early, no corruptions / insanity is propagated to the point where valuable data can be hurt; the price is lower (possibly much lower) performance because of all other checks; - do not use INVARIANTS and risk that some error would not be caught early and would cause greater harm; the upside is better performance; So people used (use) INVARIANTS to extensively test any new code/environments, but then prefer to run production systems without INVARIANTS. Now we get a new middle-ground: get both worse performance (because KASSERTs are compiled in) and a risk of harming your data (because KASSERTs no longer panic). The upside: there is no panic! There's just a log message (or etc). and chance to get more log messages because the insanity propagates. And a chance to lose your data (your customer's) - but I've already mentioned this. I am not sure that I like this kind of middle-ground. -- Andriy Gapon _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
