- Integrated Systems
- About Us
- Integrated Systems
- About Us
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
07-26-2010 03:48 AM
I am getting this waring when I add additional dumps.
I have added the entries in /etc/fstab for additional dump volumes and ran "crashconf -a ".
/dev/swap/lvol1 / dump defaults 0 0
/dev/swap/lvol2 / dump defaults 0 0
/dev/swap/lvol1: warning: no link redundancy, only primary path used for dump
/dev/swap/lvol2: warning: no link redundancy, only primary path used for dump
Inspite of the warnings , both logical volumes are added to the dump space.
DEVICE OFFSET(kB) SIZE (kB) LOGICAL VOL. NAME
------------ ---------- ---------- ------------ -------------------------
31:0x006000 207712 1048576 64:0x000002 /dev/vg00/lvol2
31:0x437200 15936 16777216 64:0x040001 /dev/swap/lvol1
31:0x437200 16793152 16809984 64:0x040002 /dev/swap/lvol2
Why we are getting those warning messages? Disks in "swap" VG is having alternate links configured. Does that warnings indicates, dump volumes will not accessed if primary fails ?
Thanks in advance.
Solved! Go to Solution.
07-26-2010 04:06 AM
Re: Getting warning while adding additional dump volumes
On systems running VxVM3.5, the swap volumes to be configured for system crash dumps should be created with the usage type as swap during the creating of the swap volume. Not doing so will cause dump corruption.
My thought is to set it up as additional swap.
Just a thought,
07-26-2010 11:41 AMSolution
/dev/swap/lvol2 _ dump _ _ _
Since those fields are ignored, it works fine, and doesn't deceive anyone into thinking that the fields have any significance.
The warnings from "crashconf -a" merely indicate that you have link redundancy available for the physical volumes in question - perhaps you have dual Fibre Channel adapters sharing the same loop.
If you do a vgdisplay -v /dev/swap, you should see "alternate path" indications in the list of physical volumes - each PV should have two or more /dev/dsk devices listed for it.
A given disk can then be accessed by either device - /dev/dsk/c0t0d0 or /dev/dsk/c3t0d0, for example.
Since a crash dump is going to take place when the system is in a poor state, by definition, the system doesn't bother with the fancy-pants link redundancy capability, since that would require determining whether or not a given primary or alternate disk target was available in the middle of a system panic.
Instead it just dumps the memory image straight out to the disk as quickly and easily as possible, to the primary path of the device.
The warning from crashconf is just letting you know that you shouldn't expect to get a crash dump if the primary PV path to your dump volumes is offline, that's all. The dumps will still work normally.
Remember that the size of a full-memory dump volume should be just a bit larger than the physical memory size, to accommodate the data identifying the dump volume contents. For our systems with 64GB of memory I create a volume that's 64GB plus one LE, or two 32GB volumes plus one LE each.
Given that crashconf isn't set to save the entire memory image, they don't really need to be quite that big, but better safe than sorry.
Also remember that dump volumes don't mirror. So if you have a mirrored volume, just create two unmirrored dump volumes each half of the total size, with one dump logical volume on each physical volume in the mirror.