Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!umix!umich!mibte!gamma!ulysses!thumper!faline!bellcore!clyde!burl!codas!usfvax2!brankley
From: brankley@usfvax2.EDU (Bob Brankley)
Newsgroups: comp.unix.wizards
Subject: Re: How does filling a disk to capacity affect performance?
Message-ID: <976@usfvax2.EDU>
Date: 13 Apr 88 20:59:11 GMT
References: <460@osupyr.mast.ohio-state.edu> <92@iravcl.ira.uka.de>
Organization: University of South Florida, Tampa, Fl
Lines: 32
Summary: Filling the disk should NOT crash the system

In article <92@iravcl.ira.uka.de>, fsinf@iravcl.ira.uka.de writes:
> > ... It goes on to say that having the
> > disk over 90% would affect its performance.  Does anyone know [...]
> > if there are any reasons not to keep a disk at 96-99%??????
> 
> Maybe the reasons are ...
> I've heard (but not verified) you can crash *every* unix-system using the
> CP-command when there is not enough space on disk. CP will not check
> whether the disk is full and overwrite blocks which are not free. The original
> data will be lost; also the machine is likely to go down.
> 
> If this isn't right, please correct.
> 


According to the paper, "A Fast File System for UNIX" the reason for
keeping a 10% of a file system free is to improve performance.  The
original studies at Berkeley suggested that reserving 10% of any generic
file system will keep the BFF(Berkeley Fast File System) efficient. 
Filling a BFF above this 10% free mark causes most BFF's to switch from
minimizing seek time to minimizing disk storage.  This is the only
reason why "newfs" on Berkeley systems automatically reserves 10% of a
file system unless otherwise instructed.  Also, the only person who is
allowed to fill a BFF above the high water mark (10% free) is "root."
When the program "df" reports a file system as 100% capacity, root can
still fill the system up an additional 10%.  The only thing that filling
the file system does is to cause many "file system full" messages on the
system console. 


Bob Brankley
CSNET:  usfvax1!brankley@usf.edu
UUCP:   {ihnp4!codas, gatech}!usfvax2!usfvax1!brankley