From owner-svn-src-head@FreeBSD.ORG Thu Sep 23 14:31:20 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19BE5106567A; Thu, 23 Sep 2010 14:31:20 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id BA5388FC1A; Thu, 23 Sep 2010 14:31:19 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o8NEVFvh035307; Thu, 23 Sep 2010 07:31:15 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C9B64B1.4090907@feral.com> Date: Thu, 23 Sep 2010 07:31:13 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Baldwin References: <201009211507.o8LF7iVv097676@svn.freebsd.org> <4C9A6EE6.5050301@freebsd.org> <20100922222441.00002f27@unknown> <201009230953.56201.jhb@freebsd.org> In-Reply-To: <201009230953.56201.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Thu, 23 Sep 2010 07:31:15 -0700 (PDT) Cc: Bruce Cran , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Andriy Gapon , Gavin Atkinson , svn-src-head@FreeBSD.org Subject: Re: svn commit: r212964 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 23 Sep 2010 14:31:20 -0000 There are a lot of accelerations that can be applied here- so much so that Panasas elected to stick with minidumps rather than go to text dumps, even though there is a fairly hard time limit that a blade can be down before more drastic error recovery mechanisms for the shelf kick in. It turns out that the big issue here was more the savecore time coming back up rather than the time of dumping. > minidumps have made the time issue less of a concern on large-memory systems > (full dumps do indeed take a long time on modern systems). I think textdumps > are just as likely to fail as regular dumps though since they both use the > same code for writing out the dump, they just write different bits to the dump > area. >