If I recall, the dump partition needed to be at least as large as RAM.

In Solaris 8(?) this changed, in that crashdumps streans were
compressed as they were written out to disk. Although I've never read
this anywhere, I assumed the reasons this was done are as follows:

1) Large enterprise systems could support ridiculous (at the time)
amounts of physical RAM. Providing a physical disk/LUN partition that
could hold such a large crashdump seemed wasteful and expensive.

2) Compressing the dump before writing to disk would be faster, thus
improving the chances of getting a full dump. (CPU performance has
progressed at a much higher rate of change than disk throughputs
have).

(I don't know what the compression ratios are, but I'd imagine they
would be pretty high).

Cheers,
-brian

On 4/25/07, Brian Hechinger <[EMAIL PROTECTED]> wrote:
On Wed, Apr 25, 2007 at 09:05:09PM -0400, Brian Gupta wrote:
>
> I do understand the reasons why you would want to dump to a virtual
> construct. I am just not very comfortable with the concept.
>
> My instinct is that you want the fewest layers of software involved in
> the event of a system crashdump.

Hmmm, that's a good point.  If ZFS is what caused the panic, you aren't
guaranteed to get a crashdump to be able to diagnose what went wrong.

Maybe raw dump devices aren't such a bad idea after all. ;)

On that note, does anyone know what the rule of thumb on dump size is?
RAM size?  RAM+swap?

-brian
--
"Perl can be fast and elegant as much as J2EE can be fast and elegant.
In the hands of a skilled artisan, it can and does happen; it's just
that most of the shit out there is built by people who'd be better
suited to making sure that my burger is cooked thoroughly."  -- Jonathan 
Patschke
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to