 Assignment Attributes |
Assignment Attributes |
The File Submission System |
 | |
Storage Quota Implementation | ||
The submit system supports a storage quota
for each assignment. The quota is enforced by
submit.cgi which handles
uploads of student work. To do this, it must know
the amount of storage currently in used for the assignment.
Rather than scanning the whole assignment directory tree to
total the storage over all uploads, the
system maintains a cache of the storage utilization in a
disk file. Submit.cgi does the following:
When the upload form is displayed it checks whether the current disk use, according the the cache file, exceeds the quota. If so, an error message is generated, and the form is generated with the fields disabled to disallow an upload.
When an upload is sent, the submit system again checks that the assignment is not full, and rejects the assignment if so. If there are no other errors, the assignment is then accepted regardless of its size.
After the assignment is stored in its final location, the amount of space used for it is totaled and added to the cached usage value.
There are a number of reasons why this procedure can allow actual disk usage to exceed the quota, the most obvious that any size submission can be added to an assignment which is not yet full. Maximum file sizes on submitted files limit the effect of this hole. This is somewhat aggravated by the fact that, by checking for the size then storing files, we create a race condition where a number of assignments arriving about the same time can all be stored, even though any one of them is large enough to pass the quota. There is also a minor issue that the incremental measurement of assignment space will miss growth of the root directory.
The upshot being that the storage limit isn't a very firm limit. It was intended to prevent the any particular assignment from using an unbounded amount of storage, and it will do that (unless you turn off size limits on individual files). Since the quota is generally a guess anyway, there seems little point is making a more expensive implementation in order to enforce it precisely.
To limit errors and for general paranoia, administrative operations on the assignment synchronize the storage cache. This is especially useful if you've made some changes to the assignment directory outside the submit system, perhaps using standard shell commands. This synchronization is done:
Whenever an assignment description is loaded, if the attempt to read the usage cache fails, an attempt is made to compute the actual usage and recreate the cache file.
Whenever the setsub command loads an assignment, either by the
interactive load command or through the command line switches
(unless -U is used to suppress it).
Whenever the assignment editor web page is first reached from the file manager link.
Whenever the editor RELOAD button is pressed in the assignment editor.
After any submissions are deleted.