Re: dumpdev in loader.conf vs rc.d/dumpon

[Andrey V. Elsukov]

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

[Slawa Olhovchenkov]

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

[Andrey V. Elsukov]

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

[Slawa Olhovchenkov]

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

[Slawa Olhovchenkov]

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

[Andrey V. Elsukov]

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

[Andrey V. Elsukov]

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

[Andriy Gapon]

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

[Slawa Olhovchenkov]

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

[Pawel Jakub Dawidek]

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

[Pawel Jakub Dawidek]

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

[Slawa Olhovchenkov]

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

[Andriy Gapon]

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

[Conrad Meyer]

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

[Conrad Meyer]

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"

Re: dumpdev in loader.conf vs rc.d/dumpon

[Andriy Gapon]

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"