87

What does size of a directory mean in output of ls -l command?

Improve this question
1

4 Answers 4

Reset to default
59

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.

Improve this answer
7
  • 6
    and when a directory contains thousands of files, the size of the directory itself can easily be > 10KB
    – glenn jackman
    Commented Feb 23, 2011 at 20:28
  • 1
    @txwikinger I think directories contain lists of inodes, not actual file names.
    – Ярослав Рахматуллин
    Commented Mar 18, 2013 at 6:36
  • 6
    @ЯрославРахматуллин A directory entry consists of an inode number and a filename.
    – 200_success
    Commented Oct 1, 2013 at 7:45
  • 4
    So the "size" of a dir is only related to the number of files inside, not the size of the files?
    – wsdzbm
    Commented Sep 9, 2016 at 14:02
  • 1
    @Lee: Yes, that's right.
    – cat
    Commented Jun 5, 2017 at 22:19
20

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.

Improve this answer
16

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.

Improve this answer
1
  • 1
    What meta-data are you referring to?
    – Stéphane Chazelas
    Commented Oct 1, 2012 at 21:27
5

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.

Improve this answer
2
  • 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. :)
    – n611x007
    Commented Jan 9, 2014 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 Chazelas
    Commented Jan 9, 2014 at 13:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .