What does size of a directory mean in output of
ls -l command?
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
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
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
..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
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
WOFSis the first Copy-on-Write filesystem and because in
WOFSfiles report the directory they are in instead of being listed in the directory. If you read a
readdir(), you only get data for the intended entries, but never for
... The link count of an empty directory on
WOFSis 1 and the whole behavior is completely POSIX compliant.
ZFS, that was implemented after reading the
ZFSis 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 entriesin
st_size, so the reported "size" has no real meaning with respect to the occupied disk space from the directory data. There are no
..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
WAFLwas written 3 years after the
WOFSpaper 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 reserves 4096 bytes (at minimum) for meta-data about itself and its contents.
Also, 4096 bytes is the default allocation unit (block) for ext2/ext3/ext4 filesystem and therefor a directory cannot be any smaller.
On different filesystems you might find directories with different default sizes, that is due to the default block size of the filesystem.
Directory sizes can also grow dynamically as they get filled, but once filled the space reserved for meta-data cannot be re-allocated without removal of the directory.
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.