zwicky@erg.sri.com (Elizabeth Zwicky) (01/09/91)
In article <321@bria.AIX> writes: >The one thing that UNIX (at least the UNIX's that I've worked with) doesn't >seem to deal with is disk quotas. One of the things that I liked about >VMS was the ability to set quotas, set a sort of "grace" quota above that, >and be able to give a user the privilege to exceed disk quotas. >Something comparable under UNIX would be useful, and no doubt there are >quite a few flavors that do use quotas ... the question being, are >disk quotas part of the POSIX standard? What flavors of UNIX out there >do have a quota scheme? I don't know about POSIX; in general, BSD-derived flavours of UNIX do have quotas, based on file ownerships. They even work adequately on non-networked file systems for some sites. Mixing quotas with NFS gives results that can be charitably described as mixed (that is to say, I do actually know of one situation in which it does work, and in all the rest it ranges from broken to incredibly broken). 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. The normal UNIX quota system works by looking at ownership of files, and allows one to set a soft quota (it nags at you if you exceed it) and a hard quota (you can't exceed it). It allows only positive non-zero quotas. It requires that quotas be explicitly set per-user-per-filesystem (that is, you must set a quota for each user on each filesystem; quotas work only per filesystem), and if they are not defaults to infinity. In most environments, it's not really satisfactory. Large sites usually run without quotas, using locally-developed schemes to monitor and control disk usage. For a discussion of one such scheme, see my paper "Disk Space Management Without Quotas" in the proceeding of the third Usenix Large Installation System Administration workshop. I would dearly love to see a paper that discussed desirable features of quota systems, and compared existing quota systems of various kinds in UNIX to what one would like to have, and suggested what someone with a large site could do. And if someone else would like to write such a paper (it would be a great topic for a LISA paper) I'd be happy to provide what help and encouragement I can. Elizabeth Zwicky (zwicky@erg.sri.com)
cornutt@freedom.msfc.nasa.gov (David Cornutt) (01/09/91)
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."
guy@auspex.auspex.com (Guy Harris) (01/10/91)
>Unix has had exactly this since around 1983, you must be referring to >SYSV. I believe SYSVR4 finally adds these and other Unix features, so >the issue is moot. Some versions of UNIX, anyway. I don't know that S5 as it comes from AT&T is the only exception; most of the code to handle quotas tends to show up in the file system, and there are a number of different file system types on UNIX systems - does AIX 3.x's journaling file system, or SGI's extend file system, neither of which are the "traditional" V7/S5 file system, have quotas? The 4.2BSD file system has them, and I suspect most systems that provide that file system support quotas on it; S5R4 is one system that does. S5R4 doesn't provide quotas on V7/S5 file systems.
guy@auspex.auspex.com (Guy Harris) (01/10/91)
>I don't know about POSIX;
They're not part of any current POSIX standard I know of (well, the only
current one, as opposed to "under development" one, is 1003.1).
Since 1003.1 is a standard to which applications are written, and since
most general applications (as opposed to administrative utilities) don't
manipulate quotas, the only thing 1003.1 would want to say about quotas
is "the following calls may fail due to disk quotas being exceeded, and
they set 'errno' to EDQUOT if that happens". However, it doesn't
happen to say that.sms@lonex.radc.af.mil (Steven M. Schultz) (01/10/91)
In article <5135@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >The 4.2BSD file system has them, and I suspect most systems that provide >that file system support quotas on it; S5R4 is one system that does. >S5R4 doesn't provide quotas on V7/S5 file systems. 2.10.1BSD (V7 filesystem) and its successor (modified V7 filesystem) has had 4.3BSD quotas since Jan 1989 (i'd put 'em in back in '88 sometime). work quite well too. Steven Schultz sms@wlv.imsd.contel.com