Re: dumpdev in loader.conf vs rc.d/dumpon
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: > > > 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? 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. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpSlioURbq3y.pgp Description: PGP signature
Re: dumpdev in loader.conf vs rc.d/dumpon
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? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
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. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpfeiUIcx0t9.pgp Description: PGP signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 02:56:55PM +0300, Andrey V. Elsukov wrote: > On 24.09.2015 14:45, Slawa Olhovchenkov wrote: > > On Thu, Sep 24, 2015 at 02:37:39PM +0300, Andrey V. Elsukov wrote: > > > >> On 24.09.2015 14:37, Slawa Olhovchenkov wrote: > >>> 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 uses dumpdev tunable? > > > > This is script try it in case dumpdev=auto, before trying swap > > partition. > > Yes. > > 1. If you did set dumpdev from loader prompt or from /boot/loader.conf, > and you didn't configured it in rc.conf, then this choice will be > applied by geom_dev. Then it will be applied again by rc.d/dumpon. > > 2. If you did set dumpdev from loader prompt or from /boot/loader.conf, > and you did configured it in rc.conf, then first of will be selected > dumpdev from loader, then will be selected one from rc.conf. > > 3. If you didn't set dumpdev from loader prompt or from > /boot/loader.conf, and you didn't configured it in rc.conf, then one of > swap partition will be selected. > > In the end we can see, if we apply the following patch, then nothing > will be affected. 1. If no swap configured in fstab, but configured dumpdev from loader prompt symlink in devfs for savecore not created. 2. If swap configured in fstab and dumpdev configured from loader prompt (and different from swap) -- dumpdev changed (unexpectedly?). > Index: dumpon > === > --- dumpon(revision 288047) > +++ dumpon(working copy) > @@ -34,11 +34,6 @@ dumpon_start() > [Nn][Oo] | '') > ;; > [Aa][Uu][Tt][Oo]) > - dev=$(/bin/kenv -q dumpdev) > - if [ -n "${dev}" ] ; then > - dumpon_try "${dev}" > - return $? > - fi > while read dev mp type more ; do > [ "${type}" = "swap" ] || continue > [ -c "${dev}" ] || continue > > > PS. loader(8) has many variables where device name is used, and none of > them uses /dev/ prefix. PS. This is another stranges: devfs may be mounted not only to /dev, but in many places /dev/ prefix is hardcoded and no notes in docs. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
On 24/09/2015 14:56, Andrey V. Elsukov wrote: > 1. If you did set dumpdev from loader prompt or from /boot/loader.conf, > and you didn't configured it in rc.conf, then this choice will be > applied by geom_dev. Then it will be applied again by rc.d/dumpon. > > 2. If you did set dumpdev from loader prompt or from /boot/loader.conf, > and you did configured it in rc.conf, then first of will be selected > dumpdev from loader, then will be selected one from rc.conf. > > 3. If you didn't set dumpdev from loader prompt or from > /boot/loader.conf, and you didn't configured it in rc.conf, then one of > swap partition will be selected. > > In the end we can see, if we apply the following patch, then nothing > will be affected. I like this. > Index: dumpon > === > --- dumpon(revision 288047) > +++ dumpon(working copy) > @@ -34,11 +34,6 @@ dumpon_start() > [Nn][Oo] | '') > ;; > [Aa][Uu][Tt][Oo]) > - dev=$(/bin/kenv -q dumpdev) > - if [ -n "${dev}" ] ; then > - dumpon_try "${dev}" > - return $? > - fi > while read dev mp type more ; do > [ "${type}" = "swap" ] || continue > [ -c "${dev}" ] || continue > > > PS. loader(8) has many variables where device name is used, and none of > them uses /dev/ prefix. > -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
On 24.09.2015 14:45, Slawa Olhovchenkov wrote: > On Thu, Sep 24, 2015 at 02:37:39PM +0300, Andrey V. Elsukov wrote: > >> On 24.09.2015 14:37, Slawa Olhovchenkov wrote: >>> 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 uses dumpdev tunable? > > This is script try it in case dumpdev=auto, before trying swap > partition. Yes. 1. If you did set dumpdev from loader prompt or from /boot/loader.conf, and you didn't configured it in rc.conf, then this choice will be applied by geom_dev. Then it will be applied again by rc.d/dumpon. 2. If you did set dumpdev from loader prompt or from /boot/loader.conf, and you did configured it in rc.conf, then first of will be selected dumpdev from loader, then will be selected one from rc.conf. 3. If you didn't set dumpdev from loader prompt or from /boot/loader.conf, and you didn't configured it in rc.conf, then one of swap partition will be selected. In the end we can see, if we apply the following patch, then nothing will be affected. Index: dumpon === --- dumpon (revision 288047) +++ dumpon (working copy) @@ -34,11 +34,6 @@ dumpon_start() [Nn][Oo] | '') ;; [Aa][Uu][Tt][Oo]) - dev=$(/bin/kenv -q dumpdev) - if [ -n "${dev}" ] ; then - dumpon_try "${dev}" - return $? - fi while read dev mp type more ; do [ "${type}" = "swap" ] || continue [ -c "${dev}" ] || continue PS. loader(8) has many variables where device name is used, and none of them uses /dev/ prefix. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 02:37:39PM +0300, Andrey V. Elsukov wrote: > On 24.09.2015 14:37, Slawa Olhovchenkov wrote: > > 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 uses dumpdev tunable? This is script try it in case dumpdev=auto, before trying swap partition. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
On 24.09.2015 14:37, Slawa Olhovchenkov wrote: > 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 uses dumpdev tunable? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
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? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
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. > 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. Did you read dumpon script and saw how it use dumpdev tunable? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
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. dumpdev at boot time can be less size, sufficient for dumping at booting, but insufficient at working time. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
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. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On 23/09/2015 19:44, Conrad Meyer wrote: > On Wed, Sep 23, 2015 at 9:05 AM, Andriy Gapon wrote: >> On 23/09/2015 18:59, Conrad Meyer wrote: >>> On Wed, Sep 23, 2015 at 7:37 AM, Andriy Gapon wrote: >> Because that's how I read the code in sys/geom/geom_dev.c. Especially >> init_dumpdev() - I believe that devtoname() returns a device name without >> '/dev/'. > > I don't think that's the primary use of the variable. See below. >>> I don't see etc/rc.d/dumpon prepending /dev to anything. >> >> Right, that's why I posted my message (bug report). > > I think the use of the variable "dumpdev" in GEOM probably > could/should be dropped. The way I found this variable was that I needed to set up a dump device before init. GEOM can do that, if dumpdev is set in kenv, as soon as a configured device is available. If a system survives until rc.d/dumpon can run, then why bother with setting dumpdev in kenv - dumpdev in rc.conf would work. > Alternatively (perhaps it is a mechanism for collecting crash dumps > before init / /etc/rc start?) Exactly. > the GEOM dumpdev code could skip over a > "/dev/" prefix when comparing against devname(), so that the GEOM use > of the variable matches the etc/rc.d/dumpon use of the variable. Yes, that's another option. But, IMO, dumpdev in kenv is only really useful if rc.d/dumpon doesn't have a chance to run. So, when rc.d/dumpon is able to run it can make a tiny concession to the way GEOM works. I do not have a strong opinion. Either option, rc.d/dumpon change or geom_dev change, is fine with me. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
On Wed, Sep 23, 2015 at 9:05 AM, Andriy Gapon wrote: > On 23/09/2015 18:59, Conrad Meyer wrote: >> On Wed, Sep 23, 2015 at 7:37 AM, Andriy Gapon wrote: > Because that's how I read the code in sys/geom/geom_dev.c. Especially > init_dumpdev() - I believe that devtoname() returns a device name without > '/dev/'. I don't think that's the primary use of the variable. >> I don't see etc/rc.d/dumpon prepending /dev to anything. > > Right, that's why I posted my message (bug report). I think the use of the variable "dumpdev" in GEOM probably could/should be dropped. Alternatively (perhaps it is a mechanism for collecting crash dumps before init / /etc/rc start?) the GEOM dumpdev code could skip over a "/dev/" prefix when comparing against devname(), so that the GEOM use of the variable matches the etc/rc.d/dumpon use of the variable. Best, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
On 23/09/2015 18:59, Conrad Meyer wrote: > On Wed, Sep 23, 2015 at 7:37 AM, Andriy Gapon wrote: >> >> I have recently discovered 'dumpdev' kernel environment variable that is >> settable, for example, from loader.conf. To me it *seems* that this variable >> has to be set to a device name / path without the leading '/dev'. > > Why? Because that's how I read the code in sys/geom/geom_dev.c. Especially init_dumpdev() - I believe that devtoname() returns a device name without '/dev/'. >> If that's so, >> then rc.d/dumpon must prepend '/dev' when passing the value of 'dumpdev' to >> dumpon(8). > > dumpon(8) opens the configured file (accessible in the normal > namespace, i.e. "/dev/ada0s1b") and uses a magical ioctl on the device > to configure it as the dump device. This is all documented in > dumpon(8). Additionally, dumpon.c is short and quite legible. Indeed. > I don't see etc/rc.d/dumpon prepending /dev to anything. Right, that's why I posted my message (bug report). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dumpdev in loader.conf vs rc.d/dumpon
On Wed, Sep 23, 2015 at 7:37 AM, Andriy Gapon wrote: > > I have recently discovered 'dumpdev' kernel environment variable that is > settable, for example, from loader.conf. To me it *seems* that this variable > has to be set to a device name / path without the leading '/dev'. Why? > If that's so, > then rc.d/dumpon must prepend '/dev' when passing the value of 'dumpdev' to > dumpon(8). dumpon(8) opens the configured file (accessible in the normal namespace, i.e. "/dev/ada0s1b") and uses a magical ioctl on the device to configure it as the dump device. This is all documented in dumpon(8). Additionally, dumpon.c is short and quite legible. I don't see etc/rc.d/dumpon prepending /dev to anything. Best, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
dumpdev in loader.conf vs rc.d/dumpon
I have recently discovered 'dumpdev' kernel environment variable that is settable, for example, from loader.conf. To me it *seems* that this variable has to be set to a device name / path without the leading '/dev'. If that's so, then rc.d/dumpon must prepend '/dev' when passing the value of 'dumpdev' to dumpon(8). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"