File space allocation/deallocation under Unix (BSD4.x)

[ron at topaz.rutgers.edu.UUCP]

Not true.  When the last reference of a file goes a way, so does the space
it took up.  What is probably misleading you is the fact that typical UNIX
directories themselves never get smaller when you delete files.  First, you
need to realize what a UNIX directory contains.  A UNIX directory only contains
file names (1-14 characters on most, variable length on BSD variants) and
pointers to the inode that that name refers to.  An inode is a data structure
that contains the "essence" of the file, information such as the owner,
permissions, access times, and where on the disk the actual data contained
in the file is stored.  When the last directory reference to that inode
is removed (there is a count kept in the inode), the inode and the data
it represents is freed.  On traditional UNIX file systems, when you delete
a directory entry, the entry is just zeroed (actually only part is zeroed)
but it's slot is left in the directory for future reuse.

Consider that you create a directory with 1000 files in it.  On a System V
file system a directory entry is 16 bytes long (14 characters for the name,
2 bytes for the inode number).  The directory would grow to 16000 bytes long.
If you removed all the files, the entries would be zapped, but your directory
would still have 16000 bytes, representing 1000 free entries.  You can compress
these "holes" by removing the directory (if it were empty) or copying the
directory over fresh by moving each file or subdirectory to a fresh directory
and discarding the old one.  However, the data blocks actually consumed by the
files disappeared as soon as no one was still pointing to them.

-Ron