Output of "show dev d" seems not correct

[Ricky Pardede]

@all : Thanks for mentioning about used and allocated. I didn't aware on this concept.
I believe my case was caused by this wrong reading.

By checking "allocated", I have found a directory that has high usage of allocated space. It's smsc$root:[log]

XXXX:SYSTEM> dir /size=(alloc,unit=byte)/total
Directory SMSC$ROOT:[LOG]
Total of 2656 files, 59.59GB

Then, I try to copy this whole directory to another one but in different disk.
The result :
XXXX:SYSTEM> dir /size=(alloc,unit=byte)/total
Directory SMSC_TRC0:[LOG]
Total of 2599 files, 287.56MB

I was surprised with the comparison result.

The original takes allocated 60GB, and the copied takes allocated just 288MB.

Can please suggest me which related setting I need to adjust on $1$DGA100 ?
Or may be I need to Jan suggestion :
SET VOLUME/REBUILD
ANAL/DISK/REPAIR ?

Thank a lot.

[Ricky Pardede]

I suspect the system disk $1$DGA100 needs to repair.

I deleted the whole files in smsc$root:[log], but still it is showing allocated space 60GB.

XXXX:SYSTEM> dir /size=(alloc,unit=byte)/total
Directory SMSC$ROOT:[LOG]
Total of 58 files, 59.40GB

I am not sure what's the cause.
Can help to suggest me the safest step to try troubleshooting ?

Thanks a lot.

[Joseph Huber_1]

Leave out the /total, and do a dir/size=all to see which files remained.
If there are none, then a rebuild and analyze/repair are the way to recover.
rebuild will free allocated/cached blocks.
analyze/repair finds files which are not in any directory, and puts them into [syslost] directory.

[Joseph Huber_1]

and by the way:
[
dir /size=(alloc,unit=byte)/total
Directory SMSC$ROOT:[LOG]
Total of 58 files, 59.40GB
]

shows there ARE still files, not just allocated
Maybe You did not delete all versions of files ?

[Ricky Pardede]

@Joseph :
Some files can't be deleted because it's locked by another process.

So you suggest me to execute :
anal/disk/repair $1$DGA100 ?

To execute this, I think I need to shutdown all applications and running queue.
Isn't it ?

[Joseph Huber_1]

[
Some files can't be deleted because it's locked by another process.
]

No, in this case a /repair will not change the situation.
Only a stop of the application locking the files will unlock them, then delete.

[p.balamurugan]

show dev d/full. you need to see the cluster_size. For example if cluster_size=200 and you are file is only 10. As per VMS it will allocate the 200 block and content may be 10 block. To reduce this while initialize you need to give the cluster_size parameters. So your disk usage will not be wasted. Here I pasted the example.

25MAY.LIS;1 6/16(it is allocated space and this value will be taken from cluster_size). In the above example you could see size of the file is 6 block. But allocated is 16 block. So you need to reduce the cluster_size value. your issue will be resolved.

[Shriniketan Bhagwat]

Hi,

If your requirement is to have larger cluster factor and want to reduce the allocated but unused blocks of the file, then you can use the $ set file/truncate command. This command truncates the file at the end of the block containing the end-of-file (EOF) marker and releases allocated but unused blocks of the file. Try this on some huge file which has larger unused and allocated blocks. Truncate the file and then check the free space on the disk. This could be better approach than deleting the file (in my opinion).

Regards,
Ketan

[Jan van den Ende]

@Ketan,

not exactly.

SET FILE/TRUNC reduces the file down to the disk cluster containing the EOF.
Then again, so does a normal close of a file, as well as SET VOLUME/REBUILD.
What you refer to is only slightly related: If a file needs to grow, the chunk of growth is the EXTEND size (can be set per file, if not uses the volume's setting) - rounded up to the next cluster size border.
If a file is NOT closed appropriately (program crash, process crash, system crash) then the extended chunk is not rounded down.

hth

Proost.

Have one on me.

jpe

[Joseph Huber_1]

The cluster size is completely irrelevant here:
the OP has 58 files summing up to a total of 59.6 GB, hold locked by an application.
Even if each of the file has once cluster allocated unused, that's nothing compared to the total size.