From owner-freebsd-current@freebsd.org Thu Sep 24 11:37:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BE76A076A2; Thu, 24 Sep 2015 11:37:16 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4A512FC; Thu, 24 Sep 2015 11:37:16 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Zf4pu-000KOc-5s; Thu, 24 Sep 2015 14:37:14 +0300 Date: Thu, 24 Sep 2015 14:37:14 +0300 From: Slawa Olhovchenkov To: "Andrey V. Elsukov" Cc: Andriy Gapon , cem@FreeBSD.org, FreeBSD Current , freebsd-rc@FreeBSD.org Subject: Re: dumpdev in loader.conf vs rc.d/dumpon Message-ID: <20150924113714.GQ21849@zxy.spb.ru> References: <5602B922.20703@FreeBSD.org> <5602CDBC.7080906@FreeBSD.org> <5602DA17.7060501@FreeBSD.org> <5603B415.2090405@yandex.ru> <20150924111850.GA3158@zxy.spb.ru> <5603DE11.7010008@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5603DE11.7010008@yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 11:37:16 -0000 On Thu, Sep 24, 2015 at 02:27:13PM +0300, Andrey V. Elsukov wrote: > On 24.09.2015 14:18, Slawa Olhovchenkov wrote: > > On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote: > > > >> On 23.09.2015 19:57, Andriy Gapon wrote: > >>> I do not have a strong opinion. Either option, rc.d/dumpon change or geom_dev > >>> change, is fine with me. > >> > >> I added the ability to set dumpdev via loader. But I wasn't aware that > >> it was used in rc.d script. > >> > >> If you have set dumpdev kenv, it will be already enabled in the time > >> when rc.d/dumpon will be run. So, I think it is useless to try to > >> enable dumpdev again. I prefer remove this old code from rc.d script. > > > > rc.d script can redirect dump to device, not available at boot time, > > iSCSI disk, for examle. > > It doesn't matter. When device will appear, it will be tasted by > geom_dev and marked as device applicable for dumping. How many dump device you can select? > > dumpdev at boot time can be less size, sufficient for dumping at > > booting, but insufficient at working time. > > This also doesn't matter. Its size doesn't checked. I am don't talk about checking size. I can know about inssuficient size of device. For example, host with 3TB of RAM, booted from small SSD. This SSD have 16GB slice for dumping. This is sufficent if trouble happen at boot time. This is insuuficient if trouble happen later, after using all 3TB. rc.d script can be used for select iSCSI destination, for dumping after succesefull boot. > Did you read dumpon script and saw how it use dumpdev tunable?