figuring dump space

[amit mehta_2]

hi,
what could be the effect of making a dumpvol
and setting it up in the LIF.
i.e.
i created a clone(vxvm rootdisk) and then using vxassist created a dumpvol in the rootdg diskgroup.
# vxassist -g rootdg make dumpvol 1g
and then set it up in LIF using,
# vxbootsetup -g rootdg rootdisk01
i don't see any changes other than an additional volume and corrosponding entry in related files.my main concern is with the effect of dumpvol in core dumps(either automatic or mannual(by taking the TOC))

thanks,
amit

[Chauhan Amit · Accepted solution]

Hello Amit,

Your question is confusing.. However i would try to answer what I have understood.

What you have done is just you have created a volume name "dumpvol" , it has no effect on the Crash-Dump.
You need to specify directory " SAVECRASH_DIR=/var/adm/crash" in the config file "/etc/rc.config.d/savecrash" , in order to make this volume as Crasg Directory.
As far as space size is concerned , it should be greater than the memory size.

-Amit

[Darrel Louis]

Hi Amit,

Can you post the output of the following command:
vxvmboot â v /dev/rdsk/cXtYdZ
Can you rephrase your question

GoodLuck

Darrel

[Frank de Vries]

Are you saying you are not getting a dump file after a TOC or that it is not created where you expected it to be ??

[amit mehta_2]

$ vxvmboot -v /dev/rdsk/c4t4d0s2

LIF Label File @ (1k) block # 834 on VxVM Disk /dev/rdsk/c4t4d0s2:
Label Entry: 0, Boot Volume start: 3168; length: 1024 MB
Label Entry: 1, Root Volume start: 5246048; length: 1024 MB
Label Entry: 2, Swap Volume start: 1051744; length: 4096 MB
Label Entry: 3, Dump Volume start: 1051744; length: 4096 MB

i can still take the TOC,as i could do earlier but what exactly has changed other than a new volume (i.e. dumpvol) in the group "rootdg".

Thanks,
Amit

[A. Clay Stephenson]

One of the reasons that you set up a separate dump area is so that you can disable the compression/saving of the dumps in /var. If you have separate dump and swap areas then you should edit /etc/rc.config.d/savecrash and set SAVECRASH=0. When swap and dump occupy the same logical or physical devices then before the swap might actually be used the dump image must be saved to another area -- this can be a very time consuming step in a reboot after a crash. On systems other than those with small amounts of memory, typically a dump space 0.25XRAM will be sufficient to capture the critical data needed for analysis of the crash.

[amit mehta_2]

hi,
i uncommented the variable
SAVECRASH=0 and also the varible SAVECRASH_DIR=/var/adm/mycrash from "/etc/rc.config.d/savecrash" and then took the TOC. the TOC was completed but i didn't get any dumps in this directory.

thanks,
Amit

[amit mehta_2]

oh i figured the blunder i did,
i did savecrash=0 (which mean disabling the saving of crash).
now after setting this variable to 1 ,it saved the dump in the desired directory.
thanks,
amit

[amit mehta_2]

Hi Stepehenson,
According to Amit chuahan, altering the variables in /etc/rc.config.d/savecrash changes the location for saving dumps.but where does this "dumpvol" come into picture?
i could have done the alteration in the"/etc/rc.config.d/savecrash" file without creating "dumpvol" in "rootdg" disk group.rite?
so how to use this "dumpvol"? and how to see the contents of this logical volume?

thanks,
amit mehta

[A. Clay Stephenson]

You don't quite understand. You set SAVECRASH=0 and then the location of the crash directory doesn't matter because you are not saving the dump in a filesystem. The dump image remains in the dedicated dump area.

You only need to save the dump image to another location if the swap area and dump area are one and the same. When the machine is rebooted and before the swap area is actually used (for swap), the savecrash routines copy the dump image into a directory BUT if you have separate dump and swap areas then there is no need to do the copy because swap activity will not overwrite the dump image.