disk space

[adarsh_4]

the total size of the disk is 4110480 blocks.
the tolal size of the files on the disk is 62151 blocks and the free space shown is 76624 blocks.
total of 3071705 blocks seems to be lost. how can we recover this space. please advise.

[Steven Schweda]

> [...] the free space shown is 76624 blocks.

Shown by what?

"ANALYZE /DISK /REPAIR"?

[GuentherF · Accepted solution]

First do a "SET VOLUME/REBUILD=FORCE" to get all the "ignored" free space back.

Then use "DIR/GRAND/SIZE=ALLOC disk:[000000...]" to find the used space.

I assume no file activity while you do that and there are no alias entries (hard links) on this volume.

If that still show thousands of "unaccounted" blocks then do the "ANALYZE/DISK/REPAIR" and try the DIR command again.

If still missing blocks check for a bit puddle under you storage system. ;-)

/Guenther

[adarsh_4]

thanks. i have a idea of what to do. thanks once again

[Hoff]

And once you get this sorted out...

'd think that the longer term solution here would be to swap these two gigabyte (2 GB) disks (RZ28?) disks for something larger. And newer.

SCSI disks in the 18 GB range can sometimes be had for the cost of shipping the bricks around, and they've probably also been spinning for a few years less than these RZ28? disks.

And (beyond the ANALYZE /DISK /REPAIR and related, there have been several cases when the free block displays have been wacky. The most recent round of ECO kits for this misbehavior arrived within the last week or three for the current releases.

[Hein van den Heuvel]

adarsh,

If you want to learn a little more about this, then be sure to pick up DFU from http://www.digiater.nl/dfu and just try the REPORT command.

Now carefully study, and try to understand each line.

Example output below.
Suggestion: $define dfu$nosmg yes

Cheers,
Hein.


$ dfu report stripe

Disk and File Utilities for OpenVMS V3.2
%DFU-I-REPORT, Reporting on STRIPE: ($1$DGA200:)

***** Volume info for ODS5 volume STRIPE: (from HOME block) *****
Volume name : STRIPE
Volume owner :
Volume set name :
Highwater mark. / Erase on del. : No / No
Cluster size : 128
Maximum # files : 827036
Header count : 40054
First header VBN : 715
Free headers : 397

***** File Statistics (from INDEXF.SYS) *****
INDEXF.SYS fragments/ map_in_use : 5 /14 words ( 9% used)
Total files (ODS2 / ODS5) : 10 / 39606
Empty files : 193
Files with allocation : 39423
Files with extension headers : 0
Files marked for delete : 0
Directory files : 4742
Contiguous files : 39317
Total used/ allocated size : 32469911 /36976128 blocks
Total headers/ fragments : 39616 /39681
Average fragments per file : 1.007
File fragmentation index : 0.014 (excellent)
Average size per fragment : 931 blocks
Most fragmented file :
$1$DGA200:[ORACLE.KITS]vms_92020.jar;1 ( 1859067/1859072 blocks; 48 fragment
s)

***** Free space statistics (from BITMAP.SYS) *****
Total blocks on disk : 213375330
Total free blocks : 176399232
Percentage free (rounded) : 82
Total free extents : 124
Largest free extent (blocks) : 106685824 at LBN: 106689408
Average extent size (blocks) : 1422574
Free space fragmentation index : 0.000 (excellent)

%DFU-I-READY, REPORT command ready

[Robert Gezelter]

adarsh,

There are a variety of ways in which space can be tied up.

One that has not been mentioned is files that were allocated space and never used to full size.

That said, it is more common to find issues that are corrected using ANALYZE/DISK/REPAIR. However, if a substantial discrepancy remains after those steps, then allocated unused space is a potential place to examine.

There is also a "problem" when the "typical" file requires less than one cluster. I have seen such "breakage" account for 25% of disk space. There are a variety of ways to address this, but they depend on the precise environment.

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

[GuentherF]

Bob,

aren't you adding some confusion here? If you use "DIR/SIZE=ALLOCATED" you get all blocks assigned to a file...used or not.

/Guenther

[Willem Grooters]

Even worse. Recalculate: Total size + free = 138775, your loss would be 4071705 blocks.

Anyway
What size do you show: used (DIR) or allocated ($ DIR /SIZ=ALLOCATED)?
What is the disk's clustersize?

Clustersize is the number of blocks that is one unit of allocation. If for instance set to 4, the smallest space to be allocated to a file will be 4 blocks: 4*512 = 2048 bytes.
If set to 64, and you have 62151 files on that disk of 1 block (smallest size possible for allocation), you will end up with approximately these figures (Math: (disksize - free space) {= occupied space} / (number of files of 1 block))

[Robert Gezelter]

Gunther,

I did write that post somewhat hastily.

DIRECTORY/SIZE=ALLOCATION will indeed work (Actually, I normally use DIRECTORY/TOTAL to yield both allocated and used values in the same pass).

My experience is that most commonly, lost free space is most often created by uncontrolled reboots. In today's environment of large disks, it is often ignored until it becomes obvious. Allocated but unused, often caused by applications or processes being terminated unexpectedly is the next most common cause.

However, with increasing cluster factors, cluster factor breakage is often an issue. Often, the number of "small" files (e.g., directories, parameter files, text files, etc.) are dramatically underestimated, leading to a large number of one and two block files allocated 60 or more blocks of space. It is often surprising how fast this phenomenon can emerge as a major problem.

The solution is to reassess the cluster factor (and then rebuild the volume) or to rearrange the file management so that there are one or more LD logical disks (virtual volumes) on the disk with far smaller cluster factors).

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