Path: utzoo!mnetor!uunet!husc6!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.unix.wizards
Subject: Re: How does filling a disk to capacity affect performance?
Message-ID: <21574@bu-cs.BU.EDU>
Date: 13 Apr 88 00:26:25 GMT
References: <460@osupyr.mast.ohio-state.edu> <92@iravcl.ira.uka.de>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.unix.wizards
Organization: Boston University Distributed Systems Group
Lines: 38

In article <92@iravcl.ira.uka.de> fsinf@iravcl.ira.uka.de writes:
|In article <460@osupyr.mast.ohio-state.edu>, czei@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@bu-it.bu.edu