Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!freedom!cornutt
From: cornutt@freedom.msfc.nasa.gov (David Cornutt)
Newsgroups: comp.unix.questions
Subject: Re: Disk quotas and the like: is there a standard?
Keywords: unix disk block quota
Message-ID: <1991Jan9.145351.3077@freedom.msfc.nasa.gov>
Date: 9 Jan 91 14:53:51 GMT
References: <321@bria.AIX> <1991Jan8.190723.22542@cubmol.bio.columbia.edu> <1991Jan8.200917.25263@erg.sri.com>
Organization: MSFC
Lines: 37

zwicky@erg.sri.com (Elizabeth Zwicky) writes:

>I wouldn't
>advise it unless you carefully test what happens when you attempt to
>go over your quota on a remote system in every possible combination of
>local and remote operating systems; a lot of combinations result in
>silent failure of over-quota writes, which is liable to upset people.

I've seen a related problem.  When I was at Gould, we used to have a bunch
of old Fortran applications (ported from MPX) that nobody had time to 
convert to C.  The Fortran I/O library had a bug that it did not check
for errors on writes on disk files, and so, when a write failed due to
a full file system, the application had no way of knowing about it.
(Meanwhile, the console got bombarded with messages...until the kernel
console message buffer filled up and the system bit the dust.)  I've
always wondered if it would be a useful system configuration option
or process option to force a "broken pipe" signal to any process
that failed a disk write due to exceeded quota or full file system.

On the subject of regulating disk usage without quotas, there are
two points to consider.  The first is that different user groups can
often be prevented from crashing into each other by dividing them
into different file systems.  (Yes, there are limits on how far
you can go with this, and it isn't very dynamic, but it works and
it doesn't add the overhead of a quota system.)  The other is that
I've found that Unix systems generally don't need quotas as much
as VMS systems do, since Unix systems don't retain file versions,
which tends to be the biggest cause of disk hoggage on VMS systems.
(Of course, VMS admins can control this by setting a default limit
on the number of file versions retained, but no one ever seems to 
do this for some reason.)

-- 
David Cornutt, New Technology Inc., Huntsville, AL  (205) 461-6457
(cornutt@freedom.msfc.nasa.gov; some insane route applies)
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."