walstad@HARVARD.HARVARD.EDU (Leonard Walstad) (09/20/86)
We have noticed that there are discrepancies between the number of
blocks reported in a show quota and the number actually found
in directories. Analyze/disk was used to determine that there were
files marked for delete, files with lost headers and multiply allocated
blocks. Perhaps someone knows how to fix these problem(s)? I imagine
that I really just need to get rid of the lost header files and the
multiple allocation problems will go away. The files marked for delete
aren't a problem? We are running MicroVMS 4.1
Thanks, Leonard Walstad. walstad@harvard (arpa,uucp,csnet)
walstad@harvunxh (bitnet)LEICHTER-JERRY@YALE.ARPA (10/08/86)
We have noticed that there are discrepancies between the number of
blocks reported in a show quota and the number actually found
in directories. Analyze/disk was used to determine that there were
files marked for delete, files with lost headers and multiply allocated
blocks. Perhaps someone knows how to fix these problem(s)? I imagine
that I really just need to get rid of the lost header files and the
multiple allocation problems will go away. The files marked for delete
aren't a problem? We are running MicroVMS 4.1
1. SOME discrepency between what show quota and directory tell you is to
be expected. This is the result of a couple of things, including the fact
that every file has at least one header block, which counts against your
quota but will never show up in a directory display. The resulting discre-
pency is usually quite small - a couple of 10's of blocks at most.
2. VMS V4.0 had a number of bugs that resulted in quota records becoming in-
correct - often wildly so. Some were fixed in 4.1, more in 4.2, yet more in
4.3. Expect continued problems as long as you stay at version 4.1.
3. Use ANALYZE/DISK/REPAIR to fix up the reported problems. If you do this
to a system disk, you'll get reports of "invalid backlinks" for various system
directories. These come about because some of the directories are pointed to
twice, (essentially) once via SYS$SPECIFIC and once via SYS$COMMON. These
"errors" are to be expected. Use /CONFIRM on the ANALYZE command, and don't
let these "errors" get repaired. (Nothing terrible happens if you do, but
F$PROCEDURE will report nonsense values for procedures in system directories.
If you do this, just run through ANALYZE/DISK/REPAIR again - there are two
possible backlinks, and every time you do a /REPAIR, the "other" set ends up
being inserted in the file header.)
4. Use DISKQUOTA's REBUILD command to correct wildly-incorrect quota values
(after doing the /REPAIR). In fact, it's probably not a bad idea to do a
REBUILD from a batch job at, say, 3AM every day.
-- Jerry
-------