On Thu, Sep 24, 2015 at 10:58:00PM +0200, Pawel Jakub Dawidek wrote: > 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: > > > > > 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. > > 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. Can be ZFS VOL act as dump device?Received on Thu Sep 24 2015 - 19:12:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC