topic Re: Disk Space in Operating System - OpenVMS

Disk Space

Mulder_1 — Wed, 10 Dec 2008 10:44:49 GMT

The disk $1$dga100 has a total block count of 35556389.

The free space reported is 12883675.
But, when issued the following command it shows :

SYSTEM1$:> dir $1$DGA100:[000000...]/siz=all/grand

Grand total of 1227 directories, 61283 files, 35996727/38823505 blocks.

Can anyone please let me know why this is reported wrongly ?

Analyse/disk can resolve this problem?

Thanks

Re: Disk Space

Jon Pinkley — Wed, 10 Dec 2008 11:04:46 GMT

Most likely there are alias directories and the same files are being counted multiple times, since they have multiple names.

Most common instance of this is the sys$common directory on a system disk.

I believe this is covered in the VMS FAQ.

Jon

Re: Disk Space

Robert Gezelter — Wed, 10 Dec 2008 11:40:41 GMT

FOX2,

Doing a quick scan of the OpenVMS FAQ (at http://hoffmanlabs.org/vmsfaq/vmsfaq.html ) I did not find this described, although I agree with Jon, the most likely cause is multiple processing of files due to aliases.

FILES-11 (all levels), unlike the *IX and Windows file structures, allows files (including directories) to be entered at multiple points in the directory tree. This is harmless to disk accounting, as most disk structure accounting is actually done by processing the Index File, not directories.

This feature is most commonly noted on system disks, where [VMS$COMMON] is entered as [SYSCOMMON] under each system root (e.g., [SYS0}, [SYS1], ... [SYS597]). Thus, having multiple OpenVMS roots on one disk only incurs the space cost of files that are particular to each instance, not a complete copy of OpenVMS for each instance sharing a system disk.

This feature of the structure predates OpenVMS, having been part of the original FILES-11 Level 1 specification for RSX-11D. It is not the same as hard/soft links, which are later additions.

Thus, when a [...] enumeration of files on the disk is done, there is the possibility that directories (and files) that are entered multiple times will be added to the total multiple times. ANALYZE/DISK_STRUCTURE (see the online HELP text) will the actual space in use by auditing the index file and storage bitmap.

- Bob Gezelter, http://www.rlgsc.com

P.S. Hoff, perhaps this should be an item in the FAQ?

Re: Disk Space

Hein van den Heuvel — Wed, 10 Dec 2008 12:40:37 GMT

DFU

Need I say more?

DFU REPORT $1$DGA100:

Still not clear?

http://www.digiater.nl/dfu

That should do it.

Regards,

Hein.

Re: Disk Space

Wim Van den Wyngaert — Wed, 10 Dec 2008 13:10:27 GMT

To answer your question : yes anal/dis/REPAIR can solve the problem but it could be normal too as the others explained.

Wim

Re: Disk Space

Hoff — Wed, 10 Dec 2008 13:45:30 GMT

The first hit in the following Google search turns up the answer:

http://www.google.com/search?hl=en&q=openvms+%22directory+%2Fsize%22+%22show+device%22+blocks

That's a search for

OpenVMS "directory /size" "show device" blocks

Which seems a pretty reasonable Google search to try to find the answer here, right?

This particular DCL detail is in the OpenVMS FAQ, in the section on DIRECTORY /SIZE and disk quotas. Certainly not as obviously placed as it should be, but a search for DIRECTORY or /SIZE through the FAQ text file or FAQ PDF will find it. Certainly not as obvious a placement given particularly that fewer and fewer sites are using disk quotas these days. But it's the same basic underlying difference in what the various commands are displaying.

Please do lob a documentation enhancement request at HP for whatever documentation you looked at. I checked DIRECTORY /SIZE here and didn't see this caveat listed, but I don't know what other documentation you reviewed before you posted this. You're far the first to encounter this confusion, as that Google search will indicate - hence it might well be good to see the DIRECTORY /SIZE documentation (and whatever else you looked at) updated.

And why the assumption that something is "wrong" or a "problem"? This can appear inconsistent, confusing, unexpected and surprising, yes. But wrong? A problem? No. Assuming an understanding in the face of an inconsistency is not an assumption that is particularly safe in the generic case. Best to figure out why first, rather than assuming an error. This approach comes to the fore as you move forward toward system and application debugging, too.