directory size includes size of ..

leostar_10 · 12-03-2007, 12:17 PM

Hi,
I have a directory with 2 files, the combined size of both being 331 bytes. But when I do ls -la, it lists 4 elements, the current directory '.' and its size being 49 bytes, the parent directory '..' whose size of 4096 bytes and the other two files I mentioned earlier whose combined size is 331 bytes.
In general, when I try to find the size of a directory, I use the du -h command, and in this case it shows it as 4.0K, it really should be just 331 bytes but I guess it is including the 4096 bytes of ..
I wonder what is the best way to find the size of all the files in the directory which does not include . and .. Also, why is the size 4096? I found this in every directory.

Thanks in advance.

matthewg42 · 12-03-2007, 12:44 PM

By default du reports the amount of disk space used by files/directories. If a file contains any data at all (even a single byte), it will occupy one block on the disk (which is typically 4k these days). One block cannot be shared between files. This means that the space of that whole block will not be available for other files, so it is considered "used".

The GNU implementation of du includes an option --apparent-size which will change the behaviour of the program to output the size of the file contents rather than the amount of disk space used by the files. For example:

Code:

$ touch zerosize
$ for (( i=0; i<100; i++)); do echo -n "x" >> less_than_a_block; done
$ for (( i=0; i<5000; i++)); do echo -n "x" >> two_blocks; done
$ ls -l
total 12
-rw-r--r-- 1 matthew matthew  100 2007-12-03 17:31 less_than_a_block
-rw-r--r-- 1 matthew matthew 5000 2007-12-03 17:32 two_blocks
-rw-r--r-- 1 matthew matthew    0 2007-12-03 17:31 zerosize
$ du -h *
4.0K    less_than_a_block
8.0K    two_blocks
0       zerosize
$ du --apparent-size -h *
100     less_than_a_block
4.9K    two_blocks
0       zerosize

Note that "total 12" refers to the total size, rounded up for block size: 8k + 4k = 12k

leostar_10 · 12-03-2007, 02:51 PM

Thanks Matthew, that helped clearing up the numbers from du. Actually, I was wrong about the fact that the size of '..' reported by ls -la is always 4096. I looked into some other directories and the value was random.

matthewg42 · 12-03-2007, 03:33 PM

Well, it's not random. It's the size necessary to store the meta-data about files (including the file names contained in that directory). The number of files / sub-directories at a given time might not map directly to the size reported, because once allocated, space is not freed if the number of files changes. This behaviour makes sense for most use cases (where disk space is cheap, and once a directory has a lot of files in it, it will probably have them again in future), and helps to reduce fragmentation.

For example:

Code:

$ mkdir testdir
$ cd testdir
$ ls -ld .
drwxr-xr-x 2 matthew matthew 4096 2007-12-03 20:28 ./
$ for ((i=0; i<1000; i++)); do touch some_longish_file_name_$i; done
$ ls -ld .
drwxr-xr-x 2 matthew matthew 36864 2007-12-03 20:29 ./
$ rm some_longish_file_name_*
$ ls -ld .
drwxr-xr-x 2 matthew matthew 36864 2007-12-03 20:29 ./
$ cd ..
$ ls -ld testdir
drwxr-xr-x 2 matthew matthew 36864 2007-12-03 20:29 testdir/
$ rmdir testdir ; mkdir testdir
$ ls -ld testdir
drwxr-xr-x 2 matthew matthew 4096 2007-12-03 20:29 testdir/

Here you see that when even empty files are created, the directory size increases - the file names and meta data must be stored somewhere, and it is in the directory object itself. In this case the file names and other meta-data fit in 9 4k blocks (36864 = 4096 * 9).

Deleting the files does not reduce the space used by the directory object - only removing the directory and re-creating it frees the space.

leostar_10 · 12-03-2007, 05:12 PM

Thanks Matthew for the excellent explaination. Appreciate it.