Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: the 10% factor
Message-ID: <20727@mimsy.umd.edu>
Date: 14 Nov 89 14:40:41 GMT
References: <21436@adm.BRL.MIL>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 33

In article <21436@adm.BRL.MIL> MATHRICH@umcvmb.missouri.edu (Rich Winkel
UMC Math Department) writes:
>I understand that allowing bsd filesystems to exceed 90% of their
>capacity results in a significant reduction in performance.

The reserved space has two functions:

	a) it speeds up block allocation: cylinder groups with no
	   free blocks in desired rotational positions are rare.

	b) it speeds up access: since (a) is true, the chance that
	   the blocks of any single file are scattered randomly
	   about the disk is low.

>... I've been told this is also true of static filesystems.

Here only part (b) matters.  If files on the file system are only
allocated once, ever, and the file system itself remains static
thereafter, there are no allocations in (a) to worry about.  The
question is then whether (b) is worth concern.  The short answer is
`probably not.'

>... if I have a 20MB partition set aside for an nfs client's swap activity,

(I can only guess that you mean `swap files for SunOS ``swap on a file''
style paging/swapping' here.  Swap partitions, in the original Unix
sense, are not file systems.)

If all the files in that partition are allocated statically---never
grow---then there is no reason to keep a 10% reserve.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris