Date: Thu, 13 Dec 2012 00:29:59 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org>, Adrian Chadd <adrian@FreeBSD.org>, Alfred Perlstein <alfred@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <50C90567.8080406@FreeBSD.org> In-Reply-To: <201212121658.49048.jhb@freebsd.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <CAJ-Vmo=U04GX%2BZyKuzXLwV%2BPpzU6_dm5BCmL=DWfsmhTVAR%2BsA@mail.gmail.com> <201212121658.49048.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C90567.8080406>