Did anyone ever notice that in the output of anlyze/disk/usage the allocated block count is always 1 higher than what e.g. directory gives with a dir/size=all?
The minimum space allocated according to this utility is 1 block, never 0. The workaround is simple: subtract 1 off the allocated size.
The used block count does not suffer from this peculiar offset of 1.
Re: analyze/disk/usage 1 block off in allocated size
Disk quota should, and apparently will, count the FILE HEADER as a block. That's a block you use, even though it has no datat. As you know, heavily fragmented, or heavily ACLed files may need more than 1 header.
Re: analyze/disk/usage 1 block off in allocated size
So.. was the file header block indeed the explanation? That would suggest 1 per file (at least) and you mentioned just a single 1. Maybe the test was with just 1 file?
Re: analyze/disk/usage 1 block off in allocated size
Better late than never:
Yes, the file header was the culprit, mainly to accommodate for disk quota to function properly. For 'entered' files as found on the system disk this gives interesting results, as there you have multiple file headers but only one allocated size.
Re: analyze/disk/usage 1 block off in allocated size
>>>> For 'entered' files as found on the system disk this gives interesting results, as there you have multiple file headers but only one allocated size.
Nitpicking...
'Entered' files (SET FILE/ENTER) have additional DIRECTORY ENTRIES, but they all have the same File-ID pointing to one and the same file header.
Of course the directory _might_ grow a block as a new file is entered.
Re: analyze/disk/usage 1 block off in allocated size
I stand corrected.
The little project I wanted to use this for (making a treemap a la Sequoia (Google) of a VMS disk ) proved to have performance issues on the graphical side anyway. Without tweaking more than I wanted to there was hardly a satisfying user experience, to coin a phrase.
