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?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"