From owner-svn-src-head@FreeBSD.ORG Wed Dec 12 22:30:12 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 320BDA9E; Wed, 12 Dec 2012 22:30:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB908FC14; Wed, 12 Dec 2012 22:30:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA07250; Thu, 13 Dec 2012 00:30:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TiuoT-000MQv-Sv; Thu, 13 Dec 2012 00:30:01 +0200 Message-ID: <50C90567.8080406@FreeBSD.org> Date: Thu, 13 Dec 2012 00:29:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin , Adrian Chadd , Alfred Perlstein Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <201212121658.49048.jhb@freebsd.org> In-Reply-To: <201212121658.49048.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:30:12 -0000 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