[Info-vax] Empty blocks in FILES-11 directory files.

[abrsvc]

On Saturday, September 24, 2022 at 1:31:31 PM UTC-4, Mark Daniel wrote:
> It seems as if directory blocks containing zero file entry records, and 
> subrecords, tend to accumulate in active directories. Can only assume 
> these arise when multi-multi-multiversion consecutive file names are 
> deleted from the directory. Recently encountered 32 consecutive empty 
> blocks at which my code sanity checked. 
> 
> Quick solution; create an equivalent directory and copy from the 
> original to the new. Problem Solvered. Assume a backup-restore would 
> accomplish similar, etc. 
> 
> Questions: 
> 
> Is this expected directory file behaviour? 
> 
> Do these empty blocks continue to accumulate, only to be reused should 
> in-order file names be created? 
> 
> Do extensive empty directory blocks represent tangible overhead to the 
> (persumably) XQP? (My code sanity checked at 32 but who knows exactly 
> how many there really were.) 
> 
> Are their tools to measure such directory file efficiency (shall we say) 
> and to "compress" such files (apart from backup-restore). 
> 
> TIA, Mark. 
> 
> PS. I do recall descriptions of the FILES-11 directory internals being 
> very simple-minded and inefficient. 
> 
> PPS. My entire technical hard-copy collection, including such VMS tomes 
> as McCoy's File System Internals, in a fit of pique, went into a recycle 
> bin some years ago. Moral of the story; don't let line-management get 
> under your skin. 
> 
> -- 
> Anyone, who using social-media, forms an opinion regarding anything 
> other than the relative cuteness of this or that puppy-dog, needs 
> seriously to examine their critical thinking.

It is my understanding that empty blocks will cause a shuffle of the entries that follow filling the block*.  Empty blocks should only exist at the end of the directory file.  Since directories are/must be contiguous, these trailing blocks will be used as space is required.  I don't believe that the extra allocated blocks is a performance hit.

* This is why deleting large numbers of files in reverse order is so much faster as all that shuffling is avoided.

Dan