Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: mod.computers.vax
Subject: Re: Lost file headers under VMS.
Message-ID: <8610080317.AA13110@ucbvax.Berkeley.EDU>
Date: Wed, 8-Oct-86 00:50:09 EDT
Article-I.D.: ucbvax.8610080317.AA13110
Posted: Wed Oct  8 00:50:09 1986
Date-Received: Wed, 8-Oct-86 04:26:18 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Organization: The ARPA Internet
Lines: 36
Approved: info-vax@sri-kl.arpa


    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
-------