From owner-freebsd-fs@FreeBSD.ORG Thu Mar 21 06:06:40 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DD82F8C for ; Thu, 21 Mar 2013 06:06:40 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 02A8BA92 for ; Thu, 21 Mar 2013 06:06:40 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id E64E1l0080x6nqcA166fHn; Thu, 21 Mar 2013 06:06:39 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id E66e1l00H1t3BNj8Y66eYY; Thu, 21 Mar 2013 06:06:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A860973A1C; Wed, 20 Mar 2013 23:06:38 -0700 (PDT) Date: Wed, 20 Mar 2013 23:06:38 -0700 From: Jeremy Chadwick To: "Reed A. Cartwright" Subject: Re: ZFS question Message-ID: <20130321060638.GA16997@icarus.home.lan> References: <20130321044557.GA15977@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363845999; bh=jWURl9cCVQ/iQZkr2W9H0HhtchnKtuRe0xLji1lZSc4=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=QbtEmLtW8e2S2DR7N558D5KFDzwUlbF/KywR3K6wzsMmkwvtvmoo1zgMprvqT3kK9 /HNNSWJzh4xyRgf1CfVbPYvOUGKnnwUUxIZXe2k9vIlbLLwPr6qc5NCo7h6mDwj/p6 lRq4yIEzJPsU5dXRdpXD9qa7+xxJ9Nf/Gxz6YYQUQcWwUm6NKp1Uug8/Nu1tbvnPIH ugP0kiN1SL74awZHLX5034mjV+JNyHJTTA6eVwjVxUpD3EMqXHu+Xss9B2yfv7MuHo UGpRNtqCjEfusR96k8vLErls2Av5xp8k5M5gS3auUcfMiUe9LQipRGiwui+KTHQfBt Npiq0SGYG+LgA== Cc: freebsd-fs@freebsd.org, Quartz , freebsd-questions@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 06:06:40 -0000 On Wed, Mar 20, 2013 at 10:10:20PM -0700, Reed A. Cartwright wrote: > {snipped stuff about CAM and mps and ZFS deadman} > > Jeremy, I have a question about enabling kernel dumps based on my > current swap config. > > I currently have a 1TB drive split into 4 geli encrypted swap > partitions (Freebsd doesn't like swap partitions over ~250 GB and I > have lots of RAM). > > These partitions are UFS-swap partitions and are > not backed by any mirroing or ZFSing. > > So, how do I best enable crash dumps? If I need to remove encryption, > I can do that. I have zero familiarity with geli(8), gbde(8), and file-based swap. My gut feeling is that you cannot use this to achieve a proper kernel panic dump, but I have not tried it. You can force a kernel panic via "sysctl debug.kdb.panic=1". I'm not sure if an automatic memory dump to swap happens with the stock GENERIC kernel however. I can talk more about that if needed (it involves adding some options to your kernel config, and one rc.conf variable). Regarding "enabling crash dumps" as a general concept: In rc.conf you need to have dumpdev="auto" (or point it to a specific disk slice, but auto works just fine assuming you have a "swap" or "dump" device defines in /etc/fstab -- see savecore(8) man page). Full details are in rc.conf(5). How this works: After a system reboots, during rc script startup, rc.d/savecore runs savecore which examines the configured dumpdev for headers + tries to detect if there was previously a kernel panic. If it finds one, it begins pulling the data out of swap and writing the results directly to /var/crash in a series of files (again, see savecore(8)). It does this ***before*** swapon(8) is run (reason why should be obvious) via rc.d/swapon. After it finishes, swapon is run (meaning anything previously written to the swap slice is effectively lost), and the system continues through the rest of the rc scripts. Purely for educational purposes: to examine system rc script order, see rcorder(8) or run "rcorder /etc/rc.d/*". -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |