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. -- 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
