In article <1993Apr14.123238.11120@oucsace.cs.ohiou.edu>, sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes:

| 1) The filesystems must all be modified to handle quotas... Essentially,
|      at least the "writing of files" mechanism must be modified to check 
|      for reached quotas before going through with the right.  Also, many
|      popular quota systems also start setting file sizes to 0 when any 
|      file is a) opened b) over quota c) used up time period or warnings.
|      So, the "opening of files" mechanism may also need to be modified.

  based on how Sun does it, and a week course on Sun Advanced
SysAdmin...

  I never saw that, and I just spent a half day playing with quotas in a
course. When you hit hard quota you stop writing. After you have been
over soft quota for a given time (in sec up to weeks) you can't write
until you get below soft quota. I never heard of or saw the o/s zap data
for you.
| 
| 2) There must be a way for quotas to be maintained.  I think BSD's approach
|      is to include a quota field in the password structure, or something
|      like that (I am not sure, though).  Most systems keep track of a file
|      called "quotas" which would determine the quotas of every user on the
|      system.

  There is a quota file for each filesystem, and it must be mounted with
the quota keyword to enable quotas. The quota is then kept "per user" in
terms of soft limit, hard limit, and time limit.
| 
| 3) Some library calls may need to be modified to handle quotas.  At the
|      minimum, every library call that has to do with writing of files, 
|      must at least check for quota violations.  I figure that a new errno
|      would be created, something like ERRQUOTA or something like that.
|      (There is probably a standard for it.)

  Yes. I don't have a pure BSD system here, so I'm not sure if any of
this is Sun speciffic.

| 
| I am sure there are others, but this is good enough for now.  I don't think
| a quota daemon (i.e. quotad? :-) ) would be good enough, since it is very
| hard to detect when a file is going to exceed a quota and stop that write
| *before* it happens.

  I think quotad handles the timer after you go over soft limit, and the
kernel does the actual enforcement. It pretty much must be to work over
multiple processes.

| 
| 2 concepts of most quota systems:
|   1) Soft Quota -> If you exceed this quota, then the writes will succeed,
|       but you will be given a time period (i.e. 1 week) or a number of
|       login warnings (i.e. 3 logins) before the quota system will take
|       action.  Taking action usually means that any file that is written
|       to, and sometimes, any file that is read, will have its filesize
|       effectively changed to 0.  This would continue until the user
|       removes enough files to go under the quota, or the quota system
|       changes enough files to reduce the quota for the user...

  I've never seen space deleted for you, you just can't write until you
get down below soft limit. Of course that may be an option, but I've not
found it in the docs. The sysadm is usually the dark force, through
scripts.
| 
|   2) Hard Quota -> This one is set higher than the soft quota, and is the
|       absolute highest amount of disk space the user can use at any time.
|       If the hard quota is reached, whatever write was going on at the 
|       time is halted and the file closed.  So, in most cases, the user
|       will be left with a file that is incomplete, but uses up the rest
|       of the hard quota.

  It will need a bunch of kernel support, since it has to be done on a
per file owner basis. If I give you write on a file I own the size goes
against my quota, not yours. Non-trivial!

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345