PMANERA@NYBVX1.BITNET (Peter Manera) (01/23/86)
We've asked your help on this problem once before, and we checked around at
DECUS, but still no answers, so one more try:
A write lock is being placed our most heavily used (many, MANY, student
accounts) RA81 by VMS. SHOW DEV DUA1/FULL gives the usual info until you get
to the last section wherein we find:
Volume status: subject to mount verification, allocation
inhibited because of error on bitmap, file high-water marking,
write-through caching enabled.
To clear the condition, we run diskquota and REBUILD the pack, but the main
question has always been - what's the problem? I've a gut feeling that it
may be our cluster size which is set to 1 - of necessity. I wrote a quick
SAS program (no, Marty, not 5.3 - we're still at 4.2 VMS waiting for SAS to
get it together) to look at filesizes and 40% of the total 40,000 files were
at 1 block. We wouldn't have enough space with a cluster of 2 or 3 (or more).
But doesn't cluster size effect bitmap size? And is it possible VMS is getting
very confused keeping track of it all? And what effect does extent size (set
at 5) have on all of this?
For what it's worth, we have the 4.3 XQP since we originally thought that had
something to do with it all. The symptom appears often (at least 4-5 times
per week) and we hoped that a full 4.2 would rectify it all, but Marty Sasaki's
SAS flame last week put us off - AGAIN!!!
Are any of you running with a cluster size of 1 with that many files (a few -
- maybe 200-300 fairly big ones) on the disk, or are you all at DEC's
recommended cluster-size of 3?
Still hoping to clear up the mystery...
Peter Manera
New York University
Graduate School of Business