Date: Thu, 24 Sep 2015 23:15:07 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, FreeBSD Current <freebsd-current@FreeBSD.org>, freebsd-rc@FreeBSD.org, Andriy Gapon <avg@FreeBSD.org>, cem@FreeBSD.org Subject: Re: dumpdev in loader.conf vs rc.d/dumpon Message-ID: <20150924211507.GB1475@garage.freebsd.pl> In-Reply-To: <20150924211151.GT21849@zxy.spb.ru> References: <5602B922.20703@FreeBSD.org> <CAG6CVpVvStV1pUi8WEBS0T5PaHxFk_HxGi8ch-LXU_DiheyTGw@mail.gmail.com> <5602CDBC.7080906@FreeBSD.org> <CAG6CVpXfBj_-cLj-8EMuAzgk6Ktmh_46e6zBBkZHMBxYW7=Cqg@mail.gmail.com> <5602DA17.7060501@FreeBSD.org> <5603B415.2090405@yandex.ru> <20150924111850.GA3158@zxy.spb.ru> <20150924205800.GA1475@garage.freebsd.pl> <20150924211151.GT21849@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 25, 2015 at 12:11:51AM +0300, Slawa Olhovchenkov wrote: > On Thu, Sep 24, 2015 at 10:58:00PM +0200, Pawel Jakub Dawidek wrote: >=20 > > On Thu, Sep 24, 2015 at 02:18:50PM +0300, Slawa Olhovchenkov wrote: > > > On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote: > > >=20 > > > > On 23.09.2015 19:57, Andriy Gapon wrote: > > > > > I do not have a strong opinion. Either option, rc.d/dumpon chang= e or geom_dev > > > > > change, is fine with me. > > > >=20 > > > > I added the ability to set dumpdev via loader. But I wasn't aware t= hat > > > > it was used in rc.d script. > > > >=20 > > > > 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 scrip= t. > > >=20 > > > rc.d script can redirect dump to device, not available at boot time, > > > iSCSI disk, for examle. > >=20 > > No. Dump device is very special. It runs in an environment when kernel > > already paniced, there are no interrupt, so there is no networking. > > Storage controllers have special methods to handle dumping kernel memory > > - it doesn't go through GEOM, it cannot go through GEOM as the scheduler > > doesn't work too. >=20 > Can be ZFS VOL act as dump device? I don't think so. IIRC there was a hack in Illumos to allocate contiguous space for dump in one of the vdevs (then I think it was extended to multiple vdevs). I don't think any ZFS feature has worked for such a ZVOL (no checksumming, no compression, etc.). Others may have more up-to-date info about that. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWBGfbAAoJEJVLhSuxKFt1ndkQAMXtDmxtA70yK28t3tpN51Cr 6soDMXK4LpyTvEti1QayQRRZZESGB9WTltadSF52Nel+AdCxnW6VqQvqDrXIZEN8 BAlWQBuHa5snaVvSGoztoTOIQRWXTIjqs1ldGudiDm/NMjvEOV9yi/YxdwAjSiEv +8G8PF0Py1cr4colzrs+EzeNsEiTYHJinmbeG2A55FPlSn5nCY9tYOgcqNCwCS03 C33IxFCMqPlKoqovb0tOPc+cy4XN/8ChKKJgj6vwsj4fUw+qaBKpy42KEoZeq6yf n4dYUNRHi08aYli9DYCRGDirlwrc8ZBq0T4cvAseUXs/7HaB2u7AlFjQCzbk3ujL A0tmjvste/F7UXfYNyrdLtMlQMfFqXPro45QgRHoshEpsITL5gVsJtOnGdyWSLP6 UPMpD1UwQwyfcbj9tP/xO+sy9MXC3B7qSTnrQAg9BqJQ9Xbln2GN7PUzXxmGZkJO SRnDy0o8sXMidZ0AqVMpxBWeW75AHJZeaDQV5mrIgAIuG3L387gDmuAl5p2+WyMg vfIC1caci6S+Guu1xQekpsHceUqfO5ytrDAtF4SZWbD8ZDEGeq2DidJbwrOgKVZ0 tMcXnYl/KB07DQ+Z0d8ruUvFQ0GJov0GA8Xc/3ukGhWvSYzevYjkHt6DdaUPNbhb hkgcIZgPm+z0DuLDtUIL =iWI/ -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150924211507.GB1475>