Date:        Wed, 15 Sep 1999 20:31:55 +0200
    From:        Guenther Grau <Guenther.Grau@bosch.com>
    Message-ID:  <37DFE61B.E33BA723@bosch.com>

  | Hmm, why does the compaction happen creation time, not when a
  | directory is deleted?

Obviously it does happen when a directory is deleted - the whole thing
is freed then ..  but I assume you mean when an entry is removed from
a directory.

unlink() only needs to find the file to be removed - once it has done that
it doesn't need to look further in the directory.   On the other hand
creat() has to scan the entire directory, in order to determine that
the name isn't already present (if it is, then creat() just turns into
open() with O_TRUNC and the directory isn't touched).

That makes it trivial for creat() (namei when acting for creat()) to
keep track of the last occupied directory slot, and then trim the directory
if there are spare blocks at the end.   On the other hand, unlink()
(namei() acting for unlink()) would have to go on and scan the rest of the
directory, where to perform its function it doesn't have to do that.
So, directory trimming is done by creat(), rather than by unlink().

  | Why are directory entries not compressed when a directory gets
  | deleted? The fs could move the entries around, couldn't it?

It could, but it isn't quite as easy as it seems - the kernel part
isn't too difficult, but the effects on applications which are scanning
the directory at the time need careful thought - and that tends to
end up suggesting that it is best to just leave the directories alone.

If some human decides to shuffle things around, that's OK, they can
then understand why some files might not have been properly found when
something else was scanning the directory - but having the kernel just
arbitrarily doing that because it feels like it might be useful probably
isn't such a wonderful idea.

  | I guess this is not done for performance reasons, right?

No.   Its the side effects.

kre