The kernel already collects unused blocks of directories.  Given a
directory that takes up 2 512 byte blocks, if you remove enough directory
entries to cause the required space to drop to 1 512 byte block, as soon as
you create another directory entry, the compaction occurs.
-Brian
On Sep 15, 12:30am, "Brian C. Grayson" wrote:
} Subject: Re: Defragmenting a NetBSD drive
} On Wed, Sep 15, 1999 at 11:22:05AM +1000, Simon Burge wrote:
} > Hubert Feyrer wrote:
} > 
} >> In article <199909022338.TAA00666@pzero.sandelman.ottawa.on.ca> you wrote:
} >>>   The file system doesn't need it. It was designed to work for long periods.
} >>>   About the only thing that may be needed is that directories that get used
} >>> a lot, e.g. /var/spool/mqueue, etc. may need to be deleted and rebuilt to
} >>> make them smaller, but that can be done with a shell script.
} >> 
} >> Wasn't this problem solved with the truncate(2) system call?
} > 
} > Not according the the man-page:
} > 
} > 	[EISDIR]      The named file is a directory.
} > 
} > If indeed it has been fixed, the doco needs updating :)
} 
}   To make a long story short, if one creates N files in a
} directory, and then deletes N-1 of them, there is no guarantee
} that the directory entry for the remaining file is in the first
} block of the directory.  In fact, if it was the last file
} created, it will be in the last block of the directory.  So
} calling truncate(2) on a directory (if it were allowed) would
} likely cause FS corruption i.e. orphaned files that can no
} longer be reached through the namespace. 
} 
}   To see this for yourself:
} > mkdir /tmp/corr
} > cd /tmp/corr
} # Make some files with really long names, to force the directory
} # to take up at least two 512-byte blocks.
} > touch `printf "%100s\n" a b c d e f g h | tr ' ' '_'`
} > rm *[a-g]
} > ls -la	# See that . is 1024 bytes.
} > od -c .	# See that the only valid entry, for ___....___h,
}  		# is at offset 0x350 or so, that is, in the _second_
} 		# 512-byte block, not the first.
} 
}   It seems possible (to me) to add re-crunching support to either
} the kernel, or a tool that works on unmounted filesystems.  If
} it's worth the effort....
} 
}   Brian
>-- End of excerpt from "Brian C. Grayson"