From owner-freebsd-hackers Sat May 10 15:21:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA27346 for hackers-outgoing; Sat, 10 May 1997 15:21:25 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA27333 for ; Sat, 10 May 1997 15:21:21 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA10744 for freebsd-hackers@FreeBSD.ORG; Sun, 11 May 1997 00:21:13 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id XAA00557; Sat, 10 May 1997 23:51:41 +0200 (MET DST) Message-ID: <19970510235141.QY09547@uriah.heep.sax.de> Date: Sat, 10 May 1997 23:51:41 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: What swap for 1Gb memory? References: <199705092351.SAA08559@nexgen.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from The Devil Himself on May 10, 1997 11:28:05 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As The Devil Himself wrote: > ..., because if the kernel panics, it dumps a complete image of memory > into the swap space, to be recovered on reboot for examination, and it can > do bad thigs if there's not enough swap. Coredumping is turned off in FreeBSD by default. It wouldn't make any sense to turn it on unless you've got a single (!) swap partition that is large enough to cover the entire physical memory. Even dumping across multiple partitions is unsupported. Whether attempts to dump core overwrite something or not is a matter of the responsible driver. The sd(4) driver seems to try to avoid this problem: nblocks = lp->d_partitions[part].p_size; /* check transfer bounds against partition size */ if ((dumplo < 0) || ((dumplo + num) > nblocks)) return (EINVAL); Well, looking again into it, it seems setdumpdev() in autoconf.c already attempts to prevent you from this accident, in that it doesn't accept a device as dumpdev if dumplo would underflow. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)