Sorry, Neo, but I must concur with jillagre. Look again at the example:

Code:

example# dumpadm –d /dev/dsk/c0t2d0s2

Dump content: kernel pages
Dump device: /dev/dsk/c0t2d0s2 (dedicated)
Savecore directory: /var/crash/saturn
Savecore enabled: yes

There are two different items being mentioned: a dump device, and an savecore directory.

The dump device is where the kernel will write the crash dump when it encounters a panic condition. This is always a raw area on disk. Remember that a panic means that the kernel has malfunctioned. No one would want a malfunctioning kernel to attempt to write a very large file into a file system. The very reason for a panic is to stop I/O to filesystems before they are more badly damaged.

The savecore program runs during a reboot (but after fsck's and thus we are sure that the filesystem can be used). Usually the dump device is not dedicated but is a swap area so we want to crash dumps before swap is needed. savecore reads from the dump area and write to the file system. We clearly need to save an image of the damaged kernel before we reboot. After a reboot, the broken kernel is gone. Note that everything quoted mentions that savecore is operating after a reboot. And the savecore description "The savecore utility saves a crash dump of the kernel (assuming that one was made)". Note that "saves" is present tense while "was made" is past tense. If a crash dump was not made, savecore can do nothing. We have already rebooted so a trick like reading from /dev/mem is not going to work... we would only get a copy of the new kernel.

Finally, look at the description of the -f option to savecore: "Attempt to save a crash dump from the specified file instead of from the system's current dump device. This option may be useful if the information stored on the dump device has been copied to an on-disk file by means of the dd(1M) command." Those are the only 2 options for input.

EDIT:
Looking over this thread, I want to make a few more points.

reborg said "It will simply not save a core dump if it has no space." And this is true. Lots of folks simply choose to not save crashdumps at all. Nothing wrong with that. Nothing reborg said implied the use of file system space as an alternative for crashdumps.

jilliagre said "You cannot limit the kernel dump size" and this is false. If there is a 12 GB crashdump to be written out, but there is only a 5 GB dump size available, the kernel will write the first 5 GB. I'm surprised that reborg implies that this used to result in a panic-reboot infinite loop. If it did that was a bug. A panic during a panic is not supposed to attempt a crashdump. A second panic should occur followed by a reboot. In addition to simply not providing a lot of space, options sometimes exist to limit crashdump size. Solaris has a few mentioned on the dumpadm man page. And about those truncated dumps... the kernel is the first thing dumped in every OS I know. I have often debugged problems by reading those truncated dumps (albeit usually on HP-UX). Simply dumping the message buffer which contains the last few messages displayed by the kernel including the panic message is a big help.