Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!sparkyfs.erg.sri.com!zwicky
From: zwicky@erg.sri.com (Elizabeth Zwicky)
Newsgroups: comp.unix.admin
Subject: Re: Summary: Do you run Unix without disk quotas?
Message-ID: <1991Mar12.003108.19963@erg.sri.com>
Date: 12 Mar 91 00:31:08 GMT
References: <1991Feb15.120048.6591@csv.viccol.edu.au> <1991Mar7.124230.6609@csv.viccol.edu.au>
Sender: news@erg.sri.com
Organization: SRI International, Menlo Park, CA
Lines: 63

In article <1991Mar7.124230.6609@csv.viccol.edu.au> timcc@csv.viccol.edu.au (Tim Cook) writes>>  3.	How much more time does the system administrator spend controlling
>> 	disk space usage, either with an alternative method of control, or
>> 	"by hand".

>For some, a very small amount of time.  For others a lot.  For all, it
>meant constant (at least daily) attention.

I find this extremely startling. It certainly isn't true here, not if
you mean from humans anyway. I do run cleanup out of cron every night,
but the only actual attention I pay to the matter is removing the
e-mail it sends me. 

>In summary, I am convinced that a hard quota system would be the most
>desired ``option'' on a Unix system used by a large number of users.  Some
>mentioned that a hard quota system would not allow a user access to a large
>chunk of disk on a ``temporary'' basis, such as would be needed to compile
>a large system, or perhaps for manipulating a large dataset.  I would
>answer this by saying ``They can ring up and ask'', or ``What about /tmp or
>/usr/tmp?''.

As someone else has pointed out, there are those of us with large
numbers of users (from nearly 200 to nearly 2,000 in my case) who find
a hard quota system literally worse than useless. In particular, users
here have a tendency to work on projects that have deadlines of the
"Finish by this time or we don't pay you" sort, and they tend to work
until those deadlines. Nobody is going to be amused if they hit a
quota at 4am with free disk space and an 8am deadline. They're going
to begrudge the lost time while they call me, and I'm going to
begrudge the lost sleep. /tmp and /usr/tmp aren't large enough, don't
persist through reboots, and aren't exported from machine to machine. 

You may be convinced that a hard quota system is the option you desire
most; but it would be hard to argue that it's intrinsically desirable,
unless you mean by "hard quota system" something rather different from
the traditional Berkeley quota system.

>The one thing I have learnt from being a Systems Administrator is
>``automate or delegate''.  All of the alternative systems were not and
>could not be fully automated.

"Were not" I'll take your word for. But "could not be" is just silly.
I can think of two ways to automate Ohio State's system off the top of
my head - put in a daemon that watches free disk space and runs the
user-warning program when it gets below a certain point, or simply
run the user-warning program from cron. Either way you'd want to add
some teeth to the user-warning program, maybe making log number of
warnings to a user and automatically initiate compression or switch
logins to a restricted shell when users racked up too many warnings.
The possibilities abound.

In any case, one should always automate dealings with programs, but
dealings with users are not always wisely automated. Controlling disk
space is a matter of managing people, and is a reasonable place to
invest some human time and judgement. A machine has trouble telling
the difference between the student with the fondness for GIFs and the
student who's doing cutting edge graphics research. This (and the
availability of cheap student labour) are why Ohio State didn't
automate in the first place. I don't have cheap student labour at SRI,
but then again I have more disk and no undergraduates. It still works
out in favour of managing disk space through semi-automated methods.

	Elizabeth Zwicky
	zwicky@erg.sri.com