SYSDAN@SEMAX51.BITNET (Mats Sundvall, Dep of Immunology, Uppsala S) (09/12/86)
Hi,
I'm trying to set up quotas on our system. We have a MVII with a RD53 and
one RA81. The RD53 is just for system software and we keep all userfiles
on the RA81. I want to activate quotas on the userdisk but I also want to
keep a scratcharea with a couple of hundred thousand block because the
users here need very big scratch files to run their programs.
Is it possible to have different quotas one one disk. I don't think it is
but you newer know. So, if anybody out there have a clue how to do, please
send me a mail.
Many thanks,
Mats Sundvall
Uppsala University
Uppsala
Sweden (sysdan@semax51.bitnet)McGuire_Ed@GRINNELL.MAILNET (09/18/86)
>Date: Fri, 12 Sep 86 12:52 EDT >From: <SYSDAN%SEMAX51.BITNET@WISCVM.WISC.EDU> (Mats Sundvall, > Dep of Immunology, Uppsala S) >Subject: disk quotas >To: info-vax@sri-kl.arpa > >I'm trying to set up quotas on our system. We have a MVII with a RD53 and >one RA81. The RD53 is just for system software and we keep all userfiles >on the RA81. I want to activate quotas on the userdisk but I also want to >keep a scratcharea with a couple of hundred thousand block because the >users here need very big scratch files to run their programs. > Is it possible to have different quotas one one disk. I don't think it is >but you newer know. So, if anybody out there have a clue how to do, please >send me a mail. Here's a solution. It is possible to allow users to charge space to a disk quota other than their "own". These special "shared" disk quotas are associated with a general identifier, instead of with a UIC. It is also possible to create a directory with attributes such that any file that is created in the directory automatically is charged to the shared disk quota, instead of the user's own disk quota. For your application, you would allow all users access to this shared disk quota, create one or more directories as described above, and use those directories as the repositories of the scratch files. This would place an overall limit on your scratch space usage, making it easy to ensure that too many simultaneous users of scratch space don't accidently use up the entire disk. The steps to follow to set this up are as follows: 1. Define a general identifier using AUTHORIZE, and give it the RESOURCE attribute. This makes it eligible to be assigned a disk quota. Example: UAF> ADD/IDENTIFIER/ATTRIBUTES=RESOURCE SCRATCH_QUOTA 2. Create a disk quota for the identifier. Example: DISKQ> USE DISK$USER DISKQ> ADD/PERM=1000000 SCRATCH_QUOTA 3. Create a directory owned by the identifier. This charges the directory file itself to the scratch quota, and causes all files created in the directory to also be charged to the scratch quota. $ CREATE/DIRECTORY/OWNER=SCRATCH_QUOTA DISK$USER:[SCRATCH] 4. Place an ACE on the directory which allows users who have been given access to the scratch area (see below) to read it and place files in it. This ACE does not allow users to see each others' files, however. $ SET DIRECTORY DISK$USER:[SCRATCH] - /ACL=((IDENTIFIER=SCRATCH_QUOTA,ACCESS=READ+WRITE)) 5. Authorize users to charge space to the scratch quota. UAF> GRANT/IDENTIFIER/ATTRIBUTES=RESOURCE SCRATCH_QUOTA MCGUIRE UAF> GRANT/IDENTIFIER/ATTRIBUTES=RESOURCE SCRATCH_QUOTA SCHULT UAF> ... Now, here are some additional notes. Step 3 causes every file created in the scratch directory to be owned by SCRATCH_QUOTA. In order for the user to be able to access her/his own files, the system also places an ACE on every file granting the creator unlimited access to the created file. You can see these ACEs by typing $ DIRECTORY/SECURITY DISK$USER:[SCRATCH] Users can create files in their own directories that are owned by SCRATCH_QUOTA. If you find that your scratch directory is empty, but that the quota usage for SCRATCH_QUOTA is large, search the disk for files owned by SCRATCH_QUOTA by typing: $ DIRECTORY/BY_OWNER=SCRATCH_QUOTA DISK$USER:[000000...] All of the operations discussed require privilege. The user doesn't need any special privilege to use the system once it's set up, however.
SKELTON%UK.AC.LSE.VAX1@AC.UK.UUCP (03/21/87)
>Using several ways to compute disk usage, these are the figures I came up >with for a particular user (note: the files for this user are pretty >static - the user did not login while I was obtaining these figures): > > 944 blocks from the DISKQUOTA utility > 860 blocks allocated - from DIRECTORY/SIZE=ALL/BY_OWNER=[?] disk:[000000... > 579 blocks used - from DIRECTORY/SIZE=ALL/BY_OWNER=[?] disk:[000000...] > 668 blocks as reported by an accounting system we are testing This is where I think the numbers come from. DISKQUOTA is usually right - unless you don't rebuild your disks after a system crash. It counts all space allocated and file header blocks. DIR shows only space used and allocated and is not necessarily relevant although there is an argument for using it. File headers are located in INDEXF.SYS and the space is allocated anyway, so that space is not available for files. I suspect that the accounting system count blocks used ( not allocated ), and file header blocks - the numbers nearly add up. It is possible that it does not count extension file header blocks - these are only present for large, very fragmented files, or files with a very long ACL. If you had given the total number of files as well, this could have been verified. The other possibility is that it is incorrectly counting the space used. If the file has no free bytes in its last used block ( eg .EXE files ), the used blocks pointer ( the end-of-file block ) in INDEXF.SYS points to the next block, which may not even be allocated to the file. This is so that this number, combined with the first-free-byte pointer, is useful. This is fairly elementary for a program which reads INDEXF.SYS, but is easily overlooked. Jeremy Skelton, London School of Economics Computer Service. JANET: J.SKELTON@UK.AC.LSE.VAX1 International: J.SKELTON@VAX1.LSE.AC.UK ARPA: J.SKELTON%LSE.VAX1@UCL-CS.ARPA