Path: utzoo!mnetor!uunet!husc6!linus!raybed2!rayssd!brunix!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven Bellovin)
Newsgroups: comp.unix.wizards
Subject: Re: How does filling a disk to capacity affect performance?
Message-ID: <10224@ulysses.homer.nj.att.com>
Date: 12 Apr 88 20:11:25 GMT
References: <460@osupyr.mast.ohio-state.edu> <92@iravcl.ira.uka.de> <937@unmvax.unm.edu>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 21

...
} >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.
} 
} Total nonsense.  CP doesn't care beans which disk blocks are free.
} The kernel does, however.  When the kernel can't find a free block, it
} doesn't just pick an in-use one.  That would be REALLY stupid.
} Instead, it just returns the ENOSPC (No space left on device) error
} code.  And usually prints something like "/usr: file system full" on
} the console.  (4.3 BSD uses the system error logger instead of the
} console).

There's actually some truth to the claim; a remarkable number of systems
will not survive the experience.  They should, of course, but it's hard
to get right.  And resource exhaustion is often not tested well, since it's
hard to fake.  I've seen systems where a debugging variable could be set
to simulate failure of arbitrary percentages of requests -- deny 30% of the
disk block requests, 10% of the mbuf requests, etc.  More developers should
do that.