4 Answers
4

This is the size of space on the disk that is used to store the meta information for the directory (i.e. the table of files that belong to this directory). If it is i.e. 1024 this means that 1024 bytes on the disk are used (it always allocate full blocks) for this purpose.

The "size of a directory" printed with ls -l is (as with any file type) the value reported by the stat() call in statbuf.st_size.

What this st_size means for directories, completely depends on the file system type. Unless you know the filesystem type and understand its concepts, you cannot deduce anything from the value in st_size.

In the historic UNIX filesystem currently usually named v7-fs, directories were repeated 16 byte entries that contained a 16 bit inode number and 14 bytes of file name. The "size" of a directory was meaningful with respect to the read(2) operation and did always grow or stay as is. The . and .. entries are created by manually hard-linking them against the current and the directory a level above. The link count for a sane empty maiden directory is 2.

In the BSD-4.2 filesystem that since 1989 (SVr4) is called ufs, directories are a series of variable length records that use a format that is not granted to be stable, so user space commands are not allowed to read this format. The "size" reported is the size in bytes as in v7-fs, the size usually grows or stays as is, but newer versions of the filesystem may shrink the size under some conditions - but not always when you may expect this. The link count reported for an empty directory is 2 as with v7-fs.

In WOFS, the filesystem I designed and implemented between summer 1988 and May 1991, directories always report the "size" 0 and never have a type of content that may be read using the read(2) call. This is because WOFS is the first Copy-on-Write filesystem and because in WOFS files report the directory they are in instead of being listed in the directory. If you read a WOFS directory using readdir(), you only get data for the intended entries, but never for . and ... The link count of an empty directory on WOFS is 1 and the whole behavior is completely POSIX compliant.

In ZFS, that was implemented after reading the WOFS papers. ZFS is a copy-on-write filesystem and its authors do not deny that they copied concepts from WOFS. Directories on ZFS report the number of directory entries in st_size, so the reported "size" has no real meaning with respect to the occupied disk space from the directory data. There are no . and .. entries in a ZFS directory, but if you call readdir(), these entries are faked and returned for the first two operations. ZFS is the only FS in the list that does not support to hard-link directories but the reported link count for directories is always 2. These two irregularities in ZFS are implemented to reduce confusion in non-POSIX historic programs.

Similar to ZFS, WAFL copies some but not all ideas from WOFS. Netapp's WAFL was written 3 years after the WOFS paper was published, WAFL is copy-on-write, but WAFL seems to report "size" values that may be the "real directory size" under the assumption that the directory has content.

A directory is a just a directory, like a phone directory. It's just a file with a list of numbers and a name next to them. Each number references a file in the file-system (an inode number) and the name is the file name.

You need disk space to save that data, how it is allocated and grown and shrunk is filesystem dependant.

you could include the actual details of what meta-data is kept and the block allocation considerations regarding the grow of size. it would make a more exact answer complete with the already given nice allegory. :)
– n611x007Jan 9 '14 at 13:19

3

@naxa, that's filesystem dependant, and even within a filesystem (like ext4), that depends on which options you enable, so I'd rather leave it as "it's filesystem dependant", rather than try and be exhaustive which would not be very relevant for this question.
– Stéphane ChazelasJan 9 '14 at 13:54