[comp.os.vms] Directory file sizes

VORBRUEG@DBNPIB5.BITNET.UUCP (08/19/87)

Some days ago, I had to move my mail directory to another disk, our
RP07's having broken down after six years of faithful service. In the
process, the size of the directory file went down from 33 to 9 blocks.

This triggered my curiosity. I had a look at some other directory files,
especially those which had seen a lively history of file creations and
deletions. I expected some unused bytes at the end of each block: this
is because in directory files, records aren't allowed to span blocks.

But the situation turned out to be worse. The file system is intelligent
enough to squeeze a block into the middle of a directory if a new file
is entered, in order to keep the alphabetical order of file names. On
the other hand, it will squeeze out a block only when it becomes
completely empty. Now, you could call this being consequent...

But in the worst case (and I have seen this), you end up with a file
containing one *block* per file in the directory, using e.g. 20 bytes
out of the 512. Think of the havoc this wreaks on directory caching!
And hasn't your SYS$SYSTEM directory seen a lot of file creations and
deletions during all those upgrades and installations?

Additionally, at the end of each block I saw, at least some 100 bytes
were free, giving an overhead of about 20% even in the best case. I
wonder whether this is connected with the record size for a maximally
long file name (94 bytes)...?

I think a utility to compress a directory file in place would be nice.
You can accomplish this now by renaming the files to a new directory,
but that's very cumbersome and probably not practical with 'live' system
directories. Especially much-used directories on slow disks should
profit from this.

Maybe somebody from DEC could comment (anybody listening except Paul
Winalski? I really appreciated his comments on the history of EVE and
LSE and his prompt reaction to a TPU bug some months ago. Keep it up!).

    Jan Vorbrueggen