Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!AC.UK!SKELTON%UK.AC.LSE.VAX1
From: SKELTON%UK.AC.LSE.VAX1@AC.UK.UUCP
Newsgroups: mod.computers.vax
Subject: Disk Quotas
Message-ID: <8703210617.AA06953@ucbvax.Berkeley.EDU>
Date: Sat, 21-Mar-87 01:18:31 EST
Article-I.D.: ucbvax.8703210617.AA06953
Posted: Sat Mar 21 01:18:31 1987
Date-Received: Sun, 22-Mar-87 23:02:06 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 33
Approved: info-vax@sri-kl.arpa

>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