On 04/12/10 11:07, Mike Shapiro wrote:
I don't understand the need for this change and as the author of
dumpadm, I object to what is proposed here.
We made a very deliberate design decision when implementing dumpadm that
the objective of having an enterprise OS with crash dumps enabled by
default is that if you want to deconfigure a dedicated dump device, then
the way you do that is by setting the dump device back to swap.
We do not want any windows of time where there is no dump device
configured, which is why we considered this during the original project
and specifically did not do it. If someone has a zvol dedicated dump
device, set -d swap to deconfigure it.
From the dumpadm man page:
swap
If the special token swap is specified as the dump
device, dumpadm examines the active swap entries and
selects the most appropriate entry to configure as
the dump device. See swap(1M). Refer to the NOTES
below for details of the algorithm used to select an
appropriate swap entry. When the system is first
installed with a UFS root file system, dumpadm uses
the value for swap to determine the initial dump
device setting. A given ZFS volume cannot be config-
ured for both the swap area and the dump device.
If you have a zfs based swap device, this doesn't work.
From the bug report, what happens is that there is a trapdoor effect
when running from the LiveCD (or any other installation image);
once the zpool has been created and configured, it is no longer
possible to unconfigure the dump device and destroy the zpool.
This makes re-invoking the installer impossible; instead a
reboot from media is required if the customer changes his mind.
The requirement to always have a dump device is a good one.
We also should make the installer restartable, if only for
testing purposes. It has been a useful debugging aid to have
dumps configured by default when running the installer as we've
hit a few kernel bugs during installation, so we'd like to
continue configuring dumps during installation.
When we boot from the liveCD, we have swap configured in
the /etc/dumpadm.conf file; since there is no swap configured
at boot the kernel disables dumps. Is there anyway we can
return to this configuration?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
opensolaris-arc mailing list
[email protected]
