Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!uflorida!gatech!purdue!haven!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Lost pages in swapfile ?
Keywords: NeXT, swapfile
Message-ID: <1991Apr18.035932.7314@ni.umd.edu>
Date: 18 Apr 91 03:59:32 GMT
References: <332@nic.cerf.net> <1991Apr17.013649.532@arizona.edu> <1991Apr17.174031.28031@sequent.com>
Sender: usenet@ni.umd.edu (USENET News System)
Distribution: world,local
Organization: University of Maryland, College Park
Lines: 17

In article <1991Apr17.174031.28031@sequent.com> gerrit@sequent.com writes:
>However, by staking out a claim to 16 or 20 Meg from
>the very beginning, you can lessen the chance that your application will
>be killed due to lack of swap space when your disk fills up.

The other reason to pre-allocate the swapfile to be used for paging rather than
having the file grow later on is performance.  The pre-allocated swapfile will
have its diskblock located "close" together so that multi-block transfers
can be accomplished without having to seek to a different cylinder to fetch
the next block.  The Berkeley fast file system attempts to keep the blocks for
a file close together, but when the disk begins to fill up, most of the bets
are off (especially on the 105MB disk where minfree is set to 5% rather than
default 10%; this is a space vs. time tradeoff).

louie

"You can tune a file system, but you can't tune a fish."