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