[mod.computers.vax] Disk Quota information

ROTONDI@IBACSATA.BITNET (Domenico Rotondi) (01/20/87)

On our VAX system I have noticed that the disk quota information
I get, whitin DISKQUOTA, whit:

SHOW *,*:

disagree whit DIRECTORY ( or DIRECTORY/BY_OWNER ) totals.
For UIC's like 1,1: the difference is very high ( for the UIC 1,1: in
particular the DIRECTORY reports a total block allocated much greater
than the DISKQUOTA number; other UIC's report a reverse situation ).

Our users frequently can't work due to DISKQUOTA exeeded.

Can anyone clarify to me this situation?

Thanks

Domenico

HELLER@cs.umass.edu (Stride 440 User) (01/22/87)

> From:           Domenico Rotondi <ROTONDI%IBACSATA.BITNET@WISCVM.WISC.EDU>
> 
> On our VAX system I have noticed that the disk quota information
> I get, whitin DISKQUOTA, whit:
> 
> SHOW *,*:
> 
> disagree whit DIRECTORY ( or DIRECTORY/BY_OWNER ) totals.
> For UIC's like 1,1: the difference is very high ( for the UIC 1,1: in
> particular the DIRECTORY reports a total block allocated much greater
> than the DISKQUOTA number; other UIC's report a reverse situation ).
> 
> Our users frequently can't work due to DISKQUOTA exeeded.
> 
> Can anyone clarify to me this situation?
> 
> Thanks
> 
> Domenico
> 
First of all, diskquota allways referes to TOTAL usage.  So, to start with
you need to do a directory/size=all, to get both the USED and ALLOCATED
blocks.  Secondly, there is a "hidden" charge for files: each file takes up
an index block in device:[000000]INDEXF.SYS.  This gets taken out of a
user's quota.  

For example, say a user has this directory:

$ dir/siz=all/tot cpm$disk:[utilities]

Directory CPM$DISK:[UTILITIES]

Total of 28 files, 266/266 blocks.
$ dir /siz=all cpm$disk:[000000]utilities.dir

Directory CPM$DISK:[000000]

UTILITIES.DIR;1           2/2     

Total of 1 file, 2/2 blocks.

The total disk quota charged is 28 + 266 + 2 + 1 = 297 blocks. That is:
28 files (= index blocks) of 266 blocks plus 2 blocks for the directory plus
an index block for the directory.

About the system UICs: very likely these UICs are actually overdrawn, but
since the processes which write these files have EXQUOTA or BYPASS
privilage, they don't get errors. Also, some of these files probably existed
before the diskquota was enabled. The numbers shown by DISKQUOTA might
change for those users if you were to do a disk quota re-build (I think it is
the REBUILD command in DISKQUOTA - warning it will write-lock the disk - it
is not something to do with users on!)

To solve your problem with users running out a disk quota: I suspect that
you are being carefull not to let the total disk quota for the disk exceed
the size of the disk. This usually means that the disk will be effectively
under-utilized. You probably should let the total disk quota for the disk
exceed the size of the disk by some small percentage (say 10-20%). This
gives the users a little extra room to handle default RMS extendions during
file I/O. Most of the time most people will be using fewwer blocks than
their disk quota allows, so over allocating the disk won't neccessarily use
up every last disk block on the disk. How much you over allocate the disk
depends on your users: do they tend to operate right on the edge of their
disk quotas? or do they tend to get paranoid if they have less than 1000 (or
2000 or more) free blocks? You probably have some mix: some users running
with less than 100 free blocks and others with thousands of free blocks.

		Robert Heller
ARPANet:	Heller@UMass-CS.CSNET
BITNET:		Heller@UMass.BITNET
BIX:		Heller
GEnie:		RHeller
FidoNet:	101/27 (Dave's Fido, Gardner, MA)
CompuServe	71450,3432
Local PV VAXen:	COINS::HELLER
UCC Cyber/DG:	Heller@CS