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

[GuentherF]

Wife-mode on...
Bob,

to get both used and allocated it is DIR/SIZE=ALL.

Wife-mode off. ;-)

Just in case there is a misconception: Any unused block of a disk cluster is included in the allocated space of the file.

/Guenther

[Richard W Hunt]

First I would run ANALYZE/DISK/REPAIR at a time when the system is relatively idle. This will move hidden or otherwise unaccounted files to [SYSLOST]. It will also delete files marked for delete but not yet deleted. If you haven't done this in a while, the number can be pretty big, particularly if you experience lots of crashes or other improper shutdowns.

Then I would run something like SET FILE [000000...]*.*;* /TRUNCATE to reclaim any whole allocated but unused disk clusters. See below for a way to find out the number of files on a disk. Your expected slack space on an optimally allocated disk is equal to the number of files times 1/2 the size of a single disk allocation unit (disk cluster).

Then I would see if the REPAIR and TRUNCATE ops got back enough space to account for the missing space.

If that was not enough, I would try to do a BACKUP of the entire disk to some other disk or a fast tape device, then restore the disk. That will defrag the volume as much as it is possible to do so. Defragging will take care of losses caused by having too big an index file.

As a sanity check, look at the INDEXF.SYS allocation. There is usually less than 100 blocks of overhead in the INDEXF.SYS, mostly due to the index bitmap and the alternate copies of the home block and boot block.

After that, if the number of blocks in the INDEXF.SYS is WAY more than the number of files on the disk, you need to clean up the index file. FYI, a command such as DIR [000000...]*.*;*/TOTAL will give you a grand total line that tells you how many files are actually on the disk. On a good disk, 1 file requires the overhead of 1 block in INDEXF.SYS, so this DIR command would give you a feel for how big INDEXF.SYS should be, within a hundred blocks or so.

It is possible to have a huge allocation due to having a lot of little files or a lot of FRAGMENTED files (so badly fragmented as to become multi-header). A backup & restore will reduce these factors to the best possible state.

[GuentherF]

"SET FILE [000000...]*.*;* /TRUNCATE"

Dainger-dainger! Some applications do not like this to be done to their files. So be careful with this.

/Guenther

[Robert Gezelter]

Gunther,

I guess that I was more asleep than I thought when I posted my comment about DIRECTORY/ALLOCATE.

Indeed, DIRECTORY accepts BOTH /SIZE:ALL and /SIZE:ALLOCATION (ALLOCATION only lists the allocated space, ALL lists both used and allocated). /SUMMARY will reduce the output to a single item per directory.

No offence taken and no apology needed. I was not careful enough when posting in the wee hours of the morning.

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