From owner-freebsd-hackers Tue Jul 9 19:29:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91EF337B400 for ; Tue, 9 Jul 2002 19:29:13 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F92243E4A for ; Tue, 9 Jul 2002 19:29:13 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0551.cvx21-bradley.dialup.earthlink.net ([209.179.194.41] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17S7Du-0002t2-00; Tue, 09 Jul 2002 19:28:59 -0700 Message-ID: <3D2B9BC0.7A8A45@mindspring.com> Date: Tue, 09 Jul 2002 19:28:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz Cc: Dmitry Morozovsky , Erik Trulsson , Chuck Robey , FreeBSD Hackers List Subject: Re: swap & huge mem systems References: <20020709161044.C77578-100000@woozle.rinet.ru> <3D2B6A45.86B061E7@mindspring.com> <20020710001249.GB541@HAL9000.wox.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Schultz wrote: > Thus spake Terry Lambert : > > You don't have to dump on your swap. It's just convenient to do. > > You can actually dump on any raw partition which is large enough. > > > > If FreeBSD intrinsically handled "suspend to disk", then you would > > need something seperate from swap, anyway. > > But in the "suspend to disk" case, you can assume you have a > non-braindead kernel. Couldn't you just allocate the blocks > in the filesystem and write your image? Sure, it would be a > bit slower than using a dedicated partition, but nobody said > "suspend to disk" is a good idea anyway. No, because in order to resume, you'd need to be running, and if you were running, then you couldn't resume anything that conflicted with the default boot state (e.g. keenel modules that were loaded post-boot). Suspend-to-disk resumption also requires that any state that you had outstanding at the time of the suspend is resumed afterward; this generally includes network state, since sockets don't get a "keepalive" unless you ask for it, and they generally stay "open" indefinitely, except for servers that have explicit idle timeouts (in which case, the client must expect to reestablish the connection, and you are still OK). The only place this really fails is "modern" UNIX kernels that attempt to treat TIME_WAIT incorrectly by setting a timer, in violation of the protocol specification. OH... and FWIW, the absolutely *best* way to install a new system is to "resume from disk" from a distribution image; you are basically running in about 6 seconds. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message