From: Scott W. Adkins (sadkins@bigbird.cs.ohiou.edu)
Date: 04/14/93


From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Subject: Re: Disk Quotas (was Re: New feature for the filesystems.)
Date: 14 Apr 1993 12:32:38 GMT

In the last article or so, nick@symphony.mp.ucc.ie (Nick Hilliard) writes:
>
>With all this talk about new features for the various filesystems, I figure
>no-one's really mentioned anything about Disk Quotas.
>
>Ok - it's fine if you're a just using Linux as a single user machine, but if
>you have a whole load of users hanging out of it, you really _do_ need some
>form of mechanism for making sure that people don't hog the machine.

Well, I have thought about these disk quotas for sometime now. One of these
days, I will actually sit down an implement them. Here is what I think is
involved:

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.

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.

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.)

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.

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...

  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.

I don't think quotas will be that hard to implement. I am concerned,
however, how to handle any modifications to the libraries, such as libc
and any of the gnu libraries. HLU? Can you give us any ideas on this?
Is it necessary?

Scott
     

-- 
         Scott W. Adkins           Internet: sadkins@bigbird.cs.ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet