Robert Milkowski writes:
> Hello Brian,
>
> Thursday, April 26, 2007, 3:55:16 AM, you wrote:
>
> BG> If I recall, the dump partition needed to be at least as large as RAM.
>
> BG> In Solaris 8(?) this changed, in that crashdumps streans were
> BG> compressed as they were written out to disk. Although I've never read
> BG> this anywhere, I assumed the reasons this was done are as follows:
>
> BG> 1) Large enterprise systems could support ridiculous (at the time)
> BG> amounts of physical RAM. Providing a physical disk/LUN partition that
> BG> could hold such a large crashdump seemed wasteful and expensive.
>
> BG> 2) Compressing the dump before writing to disk would be faster, thus
> BG> improving the chances of getting a full dump. (CPU performance has
> BG> progressed at a much higher rate of change than disk throughputs
> BG> have).
>
> BG> (I don't know what the compression ratios are, but I'd imagine they
> BG> would be pretty high).
>
> By default only kernel pages are saved to dump device so even without
> compression it can be smaller than ram size in a server. I often see
> compression ratio 1.x or 2.x nothing more (it's lzjb after all).
>
> Now with ZFS the story is a little bit different as its caches are
> treated as kernel pages so you basically are dumping all memory in
> case of file servers... there's an open bug for it.
>
Correction, it's now Fix Delivered build snv_56.
4894692 caching data in heap inflates crash dump
-r
> --
> Best regards,
> Robert mailto:[EMAIL PROTECTED]
> http://milek.blogspot.com
>
> _______________________________________________
> 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
