[comp.unix.aux] Free space on a file system

andyp@treehouse.UUCP (Andy Peterman) (08/31/90)

Its been bothering me that the 'df' command reports different values of
free space depending on whether you're logged in as the superuser.  After
reading the man pages for 'newfs' and 'tunefs' I finally understand that
10% is normally set aside for superuser use only, which accounts for the 
difference.

In the 'tunefs' documentation, it says that you can change this percentage
lower if desired, but this will reduce performance up to a factor of
three.  I'd like to set certain partitions (such as my /users partition)
so that all of it is available for anyone to use.  Is this a bad idea?
Would it really reduce performance?  I'd also like to recover part of
the 8 megs or so that are never being used in my root partition.  Does
anyone know whether this would hurt anything?  I could certainly use any
extra disk space I can find!

	Andy Peterman
	treehouse!andyp@gvgpsa.gvg.tek.com

rmtodd@uokmax.uucp (Richard Michael Todd) (09/01/90)

andyp@treehouse.UUCP (Andy Peterman) writes:
[talking about the "free space reserved" on BSD-type filesystems, and setting 
it to 0]

>so that all of it is available for anyone to use.  Is this a bad idea?
>Would it really reduce performance?  I'd also like to recover part of
>the 8 megs or so that are never being used in my root partition.  Does
>anyone know whether this would hurt anything?  I could certainly use any
>extra disk space I can find!

No, it won't hurt anything except for a possible hit in performance if you
access files created when the free disk space is low.  The reason for the 
loss in performance is this:  The Berkeley filesystem code goes to some 
effort to assure that disk blocks for files are allocated in an "optimal"
fashion -- i.e. new blocks added to files are chosen as close to the other
blocks in the file as possible in order to minimize disk seeks required
when reading the file.  (Yeah, I know this is a rather simplistic
explanation of how the BSD filesystem works; for all the gory details, you
should read Chapter 7 of _The Design and Implementation of 4.3BSD..._ by
Leffler et al.)  Obviously, when disk blocks are scarse, the filesystem
code can't allocate blocks optimally, and the time required to read files
created under such conditions increases as the files are more and more
"fragmented" (scattered over the disk).  Note that only the new files and
file blocks are affected; all previously allocated disk files are unharmed
by this performance loss.  
   So, will your disks turn to molasses if you fill up 95+% of your disks?
Well, my root partition is 96% full, and it doesn't seem to be horribly
slow (well, expect for the normal slowness one expects from Quantum 80M disks
:-)  It's still decidedly faster than it was under A/UX 1.1, with the old
SysV filesystem format.  If you need the space, I'd say go ahead and 
tunefs -m 0 that sucker.  I haven't noticed any particularly obvious
degradation as my filesystem crept past the 90% mark...
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  
"Bible-punching heavyweight evangelistic boxing kangaroos..."