From owner-freebsd-stable@FreeBSD.ORG Mon Mar 16 17:25:15 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A5EA443 for ; Mon, 16 Mar 2015 17:25:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 213305F8 for ; Mon, 16 Mar 2015 17:25:15 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1EBADB941; Mon, 16 Mar 2015 13:25:13 -0400 (EDT) From: John Baldwin To: Michael Jung Subject: Re: savecore problem Date: Mon, 16 Mar 2015 13:25:04 -0400 Message-ID: <7133006.rnVJT8O1gz@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <2142548d6fac1894597a45a042966c7a@mail.mikej.com> References: <2959054.c91S7azMUP@ralph.baldwin.cx> <2142548d6fac1894597a45a042966c7a@mail.mikej.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 16 Mar 2015 13:25:13 -0400 (EDT) Cc: freebsd-stable@freebsd.org, Brandon Allbery , Michael BlackHeart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:25:15 -0000 On Monday, March 16, 2015 11:54:52 AM Michael Jung wrote: > On 2015-03-16 11:23, John Baldwin wrote: > > On Monday, March 16, 2015 10:17:54 AM Brandon Allbery wrote: > >> On Mon, Mar 16, 2015 at 9:40 AM, Michael BlackHeart > >> > >> wrote: > >> > >> > Hello there. I've got a problem. Recently my personal server issued a > >> > kernel panic. Then there's a dump and so on. But there's no dump > >> > information after reboot. I do not know what was really the panic cause but > >> > assume that savecore failed because of RAID. > >> > > >> > Problem - minidump was done (I saw it was) but was not recovered by > >> > savecore after reboot into /var/vrash > >> > > >> (...) > >> > >> > /dev/ufs/varfs /var ufs rw,noatime > >> > 2 2 > >> > > >> > >> Last I checked, savecore had to happen very early --- before > >> filesystems > >> other than / are mounted. > > > > No, it can happen after that. What really has to happen is that you > > don't > > use swap (if you are dumping to your swap partition) before savecore > > runs. > > Can someone elaborate on not using swap as a dump device a little more? > I have > had instances in the past were I had issues with getting a core dump > and resorted to a dedicated dump device but didn't investigate further > nor have > I read this as a requirement. Typically the first swap partition is used as the dump partition. If the system writes anything out to swap before savecore runs, then it can potentially overwrite part of the core. (Note that the running kernel doesn't "know" that there is a core on the swap partition to try to preserve, it just sees that there is an available swap partition.) To try to minimize the chances of this happening, the dump is written at the end of the swap partition instead of the start, but that is not foolproof. Usually you don't run too many things during early boot before savecore that would cause swapping, though a fsck of a large filesystem might use quite a bit of RAM which could result in swapping. > A second question - Can a USB devices be used reliably for a dump device > for > ZFS on boot systems? I'm not sure if USB devices will work as a dump device or not. -- John Baldwin