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?Received on Thu Sep 24 2015 - 09:37:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC