Re: ls versus du

[Bob Proulx]

Khamis Siksek <address@hidden> [2002-08-28 23:36:59 +0300]:
> I don't know whether this is a bug or not, but I will describe for you what I 
> have noticed

Thanks for the report.  But it is not a bug.  What you are seeing is
the difference between disk space used and file size.

> There are different outputs for these utilities while I expect the same 
> behavior
> $ls -al
> $du . -a -b --max-depth=1
> 
> The difference is in the sizes they show, there is no match between them, for 
> example I have a file that its size is 201 bytes using ls and 4096 using du .
> 
> If this is not a bug?!! can you explain this behavior for me.

The 'ls -l' lists out the size of the file.  That is the number of
bytes that you would read if you opened the file and read it from
beginning to end.  This should match what you see with 'wc -c' as
well.  This is useful when talking about size of files.

The 'du' listing is different.  It lists out how much disk space you
have used.  It does not look at sizes of individual files.  It instead
asks the filesystem how many disk blocks a file is consuming.
Therefore du is useful when talking about disk space used.

Why are they different?  Because no one has ever designed a filesystem
that is 100% efficient.  Filesystems work in blocks and fragments of
blocks.  Today fragments are usually 512 bytes.  The numbers here are
not important and different filesystems do this differently.  But the
fact that files cannot be stored exactly at their file size but must
consume the entire fragment is the important concept.  The minimum
file non-zero file size is 1 byte but the file still consumes one
block which is 512 bytes and the storage ratio is inefficient.  But a
8192 size file will consume 16 512 byte fragments and be perfectly
efficient.  On average over all of the files on your disk things work
pretty well.

Note that you specifically asked du to print out the result converted
to bytes.  The natural units for du are the number of 512 byte
blocks.  But this is not natural for most humans and so there are
conversion options such as -b to bytes and -h and -H to larger units.

Also consumed but not reported are the associated inode blocks which
hold the ownership and mode information of the file.  So this as well
contributes to the overhead needed when making a filesystem on a disk.

Bob