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

[Mark Daniel]

I'll just refine my query in the bright light of the new day.

Dan has clarified the "Empty blocks should only exist at the end of the 
directory file".  I seem to recall this shuffle myself.  Can someone 
point to, or reference a resource which confirms this definitely.  This 
would mean my code could quit after the first empty block encountered 
without continuing on to EOF.  This also would imply that without 
intervention, directory files will not shrink, only grow in size.

PS. There are a number of resources out there that do not seem to 
clarify the issue of these zeroed blocks.  (Links posted as quotations 
to stop them being broken.)

> http://www.bitsavers.org/pdf/dec/vax/vms/training/EY-F575E-DP_VMS_File_System_Internals_1990.pdf
> https://web-docs.gsi.de/~kraemer/COLLECTION/VMS/ods2.txt
> https://groups.google.com/g/comp.os.vms/c/SU2YvPOeowo

and an interesting (but not immediately relevant) first-person recollection

> https://www.youtube.com/watch?v=b0YenelPw-Y

On 25/9/2022 3:01 am, 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.