MCKEEVER@UMKCVAX2.BITNET (07/27/87)
When I worked for Computing Services, we also experienced a discrepency
between what disk quota said users had and what the directory command
said. I understand that since file headers and the size of the root
directory take up some space and charge it to a uic, there is bound to
be some discrepency between what DISKQUOTA and DIRECTORY/SIZE=ALL/GRAND
tell you. But we had times when the quota wasn't even close to what was
really being used, even when you take everything you can into account,
and still added five percent for good measure. Class accounts, for
instance, with a lot of file creations and deletions could have more
than half their disk quota gone with no sign of any files holding this
much space. The problem has been noticed since 4.0. I seem to remember
hearing from somewhere that it is a known bug and that Digital is
working on it, but don't quote me on that. We've long since gone on to
bigger and better things. We fixed the problem by submitting a batch
job every night that comes alive at midnight and does an
ANALYZE/DISK/REPAIR on all of our disks. Since then, we haven't
experienced the problem to such a great extent. Granted, this locks out
access to the disks, but with it running that late at night, it has a
minimal effect on users. Only a couple have mentioned noticing a big
delay in response time around midnight.
The reason I'm sending this at all, is to point out that it was not the
person's imagination that there disk quota numbers are not accurate.
There does seem to be a problem with how RMS keeps tracks of these
things. I appreciate everybodys good intentions at pointing out that a
DIRECTORY/SIZE=ALL doesn't account for all of a uic's disk usage, but it
should come a lot closer that it does on occasion. These people may not
have ever noticed the problem since it seems directly related to the
amount of disk traffic you have, (i.e. a lot of file creations and
deletions) of which we have a lot. And if DEC has already fixed this
problem (I didn't notice it in any of the release notes since 4.0, we're
at 4.5) please forgive my ignorance.
-------------------------------------------------------------------------
UMU UMUMUMUMUM Brian McKeever
UMU UMUMUMUMUM
UMU UMUMUMUMUM University of Missouri Kansas City
U UM U Computer Science
U UM UM UM 4747 Building Rm. 219
UMUMUMUM UMUM UMUM 5100 RockHill Rd.
UMUMUMUM UMUM UMUM Kansas City, MO 64110
UMUMUMUM UMUM UMUM BITNET: MCKEEVER@UMKCVAX1
-------------------------------------------------------------------------