How does filling a disk to capacity affect performance?

Jim Frost madd at bu-cs.BU.EDU
Wed Apr 13 10:26:25 AEST 1988


In article <92 at iravcl.ira.uka.de> fsinf at iravcl.ira.uka.de writes:
|In article <460 at osupyr.mast.ohio-state.edu>, czei at osupyr.mast.ohio-state.edu (Michael S Czeiszperger) writes:
|> [...] the 'df' command adjusts the reading so that when it says 100% full,
|> the disk really is only 90% full.  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.

Well, I've seen filesystems hit 100% on various occasions here.  The
only time I've seen them crash was when /tmp resided on the same
partition.

Presumably the system can stay up until some critical process needs to
write to a full filesystem; when that happens you've got real trouble
and the system crashes.  On one of the machines here, I've seen /tmp
fill up and the system run for 5 or 10 minutes before crashing for
whatever reason.  Even this might be a bad indicator, since /tmp and
/usr/spool lived on the same partition.

>From a user point of view, things are a little different.  When the
file system denies writes, all kinds of programs break and the system
is unusable, even if it *is* still running.  Obviously you want to
avoid this.

For performance reasons, you should keep the filesystem within the
boundaries.  About the only time I can imagine where you wouldn't care
is with a static filesystem -- one that contains files that are not
going to change for quite some time.  Performance isn't a question
since you can set it up for optimum performance in advance, and since
no writes are going to take place, you're not at risk of a crash.

jim frost
madd at bu-it.bu.edu



More information about the Comp.unix.wizards mailing list