Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!ucbvax!kre From: kre@ucbvax.ARPA (Robert Elz) Newsgroups: net.micro.att,net.unix-wizards Subject: Re: disk quotas Message-ID: <9725@ucbvax.ARPA> Date: Wed, 7-Aug-85 04:10:04 EDT Article-I.D.: ucbvax.9725 Posted: Wed Aug 7 04:10:04 1985 Date-Received: Sat, 10-Aug-85 22:41:19 EDT References: <133@maynard.UUCP> <396@cuae2.UUCP> <1025@ulysses.UUCP> <118@desint.UUCP> Organization: University of California at Berkeley Lines: 28 Xref: linus net.micro.att:442 net.unix-wizards:11438 Summary: How do I handle disk full conditions automatically? In article <118@desint.UUCP>, geoff@desint.UUCP (Geoff Kuenning) writes: > If Berkeley (or AT&T) would put as much effort into > the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily > stop using quotas. I would love to somehow handle full disk conditions gracefully, but can you suggest how? Swap errors (swkill stuff) is easy - kill the process with the problem. If the system had paniced the process would be killed anyway, so its no worse off, and the rest of the processes are considerably better off for not panicing. But how do I handle a full disk? Killing some random process won't fix it (not even killing ones writing to the full filesys). I could just delete some random files - but somehow I suspect their owners might get upset. So, does anyone have any good suggestions on how to sensibly handle full discs? The problem is really one of user control - only users know which of the allocated blocks on the disk contain useful information, and which contain trash. This seems to be a situation where avoiding the problem (by simply plugging in another eagle every week for preference, disk quotas if that answer isn't viable) is the only reasonable action. Robert Elz ucbvax!kre