[ About disk free size...]

[BG Jeong]

Our system is some problem.

$ sh dev HGVXC$DKA0 /full
.........
Error count 0
Total blocks 35553280
Sectors per track 64
Total cylinders 34720
Tracks per cylinder 16
Free blocks 3271640
Maximum files allowed 493795
...........

AND

$ sh def DKA0:[000000]
$ dir [...] /total /size
Total of 10187 files, 7847942 blocks.
Grand total of 214 directories

35553280(Total blocks) - 3271640(Free blocks) = 32281640 blocks.

I think that 7847942(dir [...] /total /size) must same 32281640 blocks.

please, explain that status.

[Aaron Lewis_1 · Accepted solution]

What is the cluster size on this disk? Each file will occupy at least 1 cluster, reguardless of physical size of the data.

You need to do a SIZE=ALLOCATED:
dir [...]/grand/siz=all

The unqualified DIR command gives the actuall physical size of the the files, but does not include the space used up by empty, but allocated blocks.

i.e. a file that contains a single charactor will still use up and entire cluster of blocks.

[Jan van den Ende]

The answer by Aaron explains a (big?) part of the difference.

But, there is more.
If someone has temporary files in use during your DIR command (for example, SORT workfiles), those DO use diskspace, and ARE subtracted from Free Blocks, but do NOT show in DIR.
A second source of difference is blocks that are "Incorrectly marked allocated". You can see those with ANAL/DISK and with DFU. Both can also correct that (together with some other device housekeeping cleanups).

Hope this helps,

Proost.

Have one on me.

jpe

[Joseph Huber_1]

No, not at all: 2 main reasons:
1. You see only blocks used, not the bigger number of blocks allocated, and do not see the directory,header, and volume overhead with the directory command.

2. a directory listing lists (and adds the size) also all alias files/directories, which can lead to a much higher than real number of blocks.

But here, you seem to have a different problem: You actually see almost nothing, only 7M out of 32M blocks!
Are You sure it was HGVXC$DKA0:[000000] when You did the directory ?
If yes, then there must be big amount of either big/many files with much allocated but not used space OR many/big files not in any directory ("lost files").
Do the same directory after an analyze/disk/repair.
If it is still not o.k. afterwards, then there must be files with huge amount of allocated unused space: the best tool to find those is the freeware DFU utility:
DFU search HGVXC$DKA0 /over_allocated=

[Jan van den Ende]

Your info on the disk does not show your cluster-size.
If you INITted it without specifying /CLUSTER, then the cluster size is quite big. And if you have a lot of very small files, then A LOT of space is unused!

That leads to the next question: What version of VMS are you on?
The hard link between disk size and minimum cluster size was only relaxed starting with VMS 7.2 (and I am not sure if that includes VAX, I think it does NOT!)

Proost.

Have one on me.

jpe

[Joseph Huber_1]

The cluster size cannot be the reason for the big amount: it's a 17GB disk, the default cluster size is about 35 blocks, for 10187 files this results in no more than 180MB wasted.
The big amount of some 15GB must be in lost/invisible files!
I'm not sure if analyze/disk/repair corrects also the cache.
A SET VOLUME/REBUILD=FORCE
could correct the free amount further, but I can't imagine 15GB lost by /NOREBUILD.

[Joseph Huber_1]

One more possibility to diagnose:
What does
DFU report HGVXC$DKA0:
tell about total used/allocated say , based on the INDEXF.SYS analysis ?

If the system is pre-VMS 7.3 (pre 7.2 ?), then another possibility are hidden "deep" directories: if You don't know the history of the disk, could it be that there are directories 8 level deep, which have been used as "concealed devices" ?
Such directories would not be seen by a Dir [...] in those old VMS versions.
If dir [*.*.*.*.*.*.*.*]*.dir is not empty, then this is the case, and You have to define a concealed device pointing to such a directory, and start the search there.

[Travis Craig]

> If the system is pre-VMS 7.3 (pre 7.2 ?), then another possibility are hidden "deep" directories . . .

Whoa! 10 points for obscurity, Joseph!

--Travis

[Rudolf Wingert]

Hello,

you must expand your directory command with the [0,0] directory. There are a few big file (bitmap, indexf ... Also you have to use the allocation size of files, not the blocks in use.

Best regards Rudolf Wingert

[Joseph Huber_1]

Obscurity ? I just don't know if the 8 directory level restriction was lifted in 7.3 or already in 7.2.
Definitely it was there up to VMS 7.1:
A demonstration what it means:

OpenVMS V7.1 on node H1CALA 27-APR-2005
HUBER_H1CALA: dir $2$DKB300:[_USER.HUBER.1.2.3.4.5.6]
Directory $2$DKB300:[_USER.HUBER.1.2.3.4.5.6]
7.DIR;1
Total of 1 file.
HUBER_H1CALA: dir $2$DKB300:[_USER.HUBER.1.2.3.4.5.6.7]
%DIRECT-E-OPENIN, error opening $2$DKB300:[_USER.HUBER.1.2.3.4.5.6.7] as input
-RMS-F-DIR, error in directory name
HUBER_H1CALA: sh log/full deep
"DEEP" [super] = "$2$DKB300:[_USER.HUBER.1.2.3.4.5.]" [concealed] (LNM$PROCESS_TABLE)
HUBER_H1CALA: dir deep:[*...]
Directory DEEP:[6]
7.DIR;1
...
Directory DEEP:[6.7.8.9.10.11]
12.DIR;1
Total of 1 file.


A directory command can't see anything deeper than [_USER.HUBER.1...6], and can't count the blocks allocated for files there.
But one can fill the disk with files in deep:[*...] !

[BG Jeong]

Thanks everybody so much.

Actually, strange events happened on our system.
when i heard that system did not communicated with PLC, i commanded
"show dev d".
however, disk size increased rapidly.
I rebooted system because have no idea.

I should have "anal/disk/repair".. ^^

but, where is DFU utility download site?

thanks.

[Joseph Huber_1]

DFU is on the VMS Freeware CD.
Go from the ITRC site to the HP OpenVMS main page, there You will find the link to the freeware pages.

[Martin Vorlaender]

The latest freeware CD version of DFU can be downloaded at http://h71000.www7.hp.com/freeware/freeware70/dfu/ for Alpha and I64.

HTH,
Martin