Document Version: 0.9 - 02/12/2003
http://www.andrew.cmu.edu/~wcw/work/ss-quota.html
Bboard:
https://bboard.andrew.cmu.edu/archive/mailbox.php?mailbox=org.acs.asg.project.ssq
Test site:
http://halcyon.andrew.cmu.edu/kweb-cgi/ssq.cgi
Quota increases for AFS and Cyrus have traditionally been done by administratively increasing the amount. AFS user quotas have been fixed and no quota increases are allowed. Cyrus quotas have been set at an initial value but a request to the Help Center may result in the quota being increased.
The Help Center reports that quota increases take up a significant amount of time and would like to see this be something a user can automatically request.
At this point in time, we have the capacity to increase quotas significantly for both AFS and Cyrus. However, rather than increasing everyone's quota across the board and then prohibiting quota increases, we would prefer to have the user go to a web page to request more space.
In this manner, we have a better idea on how many people actually want more space. Also, in the case of email, if people do not use their account, spam and other junk mail will only accumulate up to the point of the default quota when the account is created instead of increasing to the maximum quota that all users are allowed. This way, we should have less junk sitting around.
The service names currently are: afs for AFS; cyrus for Cyrus.
The file will just contain the maximum quota a user can increase to. The file will be in 1K blocks, e.g. 200000 will be 200MB.
There will be a set of users that are not allowed to increase their quota. These users will be referred to as ineligble. Ineligble users are are defined as those without an eduPersonPrimaryAffiliation or an eduPersonPrimaryAffiliation that is sponsored.
At this point in time the string sponsored may be of mixed case so any comparison must ignore the case of the string.
ADM will fork a program to do the check. As such, the check is likely going to be done twice -- once as when the UI loads and another time when ADM runs. This is likely to be slow but the frequency of execution should be low enough that it won't matter.
As a first pass, the maximums will be:
Answered in section 2.3.
Addressed in 4.3
If we provide a command line utility to perform the same functionaltiy, it probably would be good to make sure it can't be run from the .login (or at least not without some negative consequences). The reason for this is that there may be load issues (and the resulting slow down may just be the consequence) that we just don't want to incur on every user login.
Anyone can purchase additional disk space at this time. Details are at http://yendi.cc.cmu.edu/work/xq/.
This system is not scalable and so the costs are very high. It would be good to be able to provide cost recovery storage services so that anyone could purchase more storage at a better price point. For example, students may be able to buy more central space from the computer store or online.
Currently, our MacOS X cluster implementation uses the user's AFS home directory to store preference information. This preference information is not automatically garbage collected and so will not shrink unless the user takes explicit action.
The preferences are stored as discrete files so deletion should be fairly straightforward by the end user. A program like clean could tag the file for deletion but we generally do not want to automatically clean up since we do not know whether or not the user will actually care if their preferences gets nuked.
This project will not directly address this issue. It will only indirectly help by giving users a larger AFS quota.
At this point, DAMS integration/representation will be deferred until the future.
We have been discussing a couple of methods for DAMS integration.
Increasing the quota on project volumes is being deferred until such a time we can revisit the management of project volume in general.
0.9 - 02/12/2003 - minor updates to paths and such. 0.8 - 01/21/2003 - revised based on meeting yesterday. Updated MacOS X foo after talking with Joe. 0.7 - 01/13/2003 - revised based on meeting today. 0.6 - 01/06/2003 - add open issue about MacOS X prefs; command line 0.5 - 01/06/2003 - revised based on meeting today 0.4 - 01/05/2003 - add DAMS management; add xq; cleanup 0.3 - 12/11/2002 - Add grm comments 0.2 - 08/29/2002 - Add MacOS X thing per Joe. 0.1 - 08/28/2002 - Initial revision.