Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
up vote 27 down vote accepted

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.

share|improve this answer
    
and when a directory contains thousands of files, the size of the directory itself can easily be > 10KB – glenn jackman Feb 23 '11 at 20:28
    
Sure. Let's say each filename has on average 10 characters. Then the storage for 1000 file names alone would take almost 10KB as space. However, it depends also on the file system. Some file systems have limits on the number of files in a directory. – txwikinger Mar 9 '11 at 21:10
1  
@txwikinger I think directories contain lists of inodes, not actual file names. – Ярослав Рахматуллин Mar 18 '13 at 6:36
4  
@ЯрославРахматуллин A directory entry consists of an inode number and a filename. – 200_success Oct 1 '13 at 7:45

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.

share|improve this answer
1  
What meta-data are you referring to? – Stéphane Chazelas Oct 1 '12 at 21:27
1  
details depend on the filesystem but generally includes meta-data like filename, inode number, file type (file, dir, fifo, socket, device node, symlink, etc), owner, group, permissions, attributes, ACLs, symlink targets. – cas Oct 1 '12 at 21:58
5  
@CraigSanders, the directory contains object name and corresponding inode number only. The inode contains the type of object, owner/group, permissions, reference to wherever ACLs and extended attributes are kept, ... Anything else will cause severe breakage of POSIX filesystem semantics. – vonbrand Mar 15 '13 at 15:05

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.

share|improve this answer
    
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 Jan 9 '14 at 13:19
1  
@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 Jan 9 '14 at 13:54

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.