Skip site navigation (1)Skip section navigation (2)
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>