dburrows/ blog/ entry/ from-blogspot/ Where have all the bytes gone?

Here's an "interesting" phenomenon I noticed on my new (not-Linux-hating) 4GB portable music player:

daniel@jeeves:~$ df -h /media/IAUDIO Filesystem Size Used Avail Use% Mounted on /dev/sdb 3.8G 3.8G 0 100% /media/IAUDIO daniel@jeeves:~$ du -hcs /media/IAUDIO 2.3G /media/IAUDIO 2.3G total

Just in case "df" and "du" had different notions of how large a gigabyte was, I asked them to tell me the number of bytes instead, with about the same result.

I won't comment on the fact that I paid for 4GB but got 3.8GB; that's typical (whoops, I just did). But where'd that extra 1.5GB go? FAT can't seriously be imposing a >50% overhead on file size, can it?

The end result here is that on my 4GB music player, I can store only a little more than 2GB of music. Boo. :-(

[UPDATE]: running fsck revealed that I had 1.5 GB in lost clusters on this filesystem and gave me my space back. Since this device is almost brand-new, I'm puzzled about how this happened...but oh well, it seems to be fixed easily enough.

Comment by Mike at 11:36 PM:

Are the inodes full?

In that case try df -i

Comment by Wouter Verhelst at 2:42 AM:

FAT doesn't have inodes

Comment by Anonymous at 2:43 AM:

Is that FAT32? How large are your clusters? If you're having clusters of 32k, that means you can lose up to 32k - 1 byte per file, which adds up if there's lots of files.

Comment by dburrows at 6:11 AM:

Hm, well, the current number of files is

daniel@jeeves:~$ find /media/IAUDIO | wc -l 656

So if we take the missing 1.5GB and divide it by 656 files, that's ... um ... somewhat more than two megabytes per file. Ow. I think that probably rules out any sort of per-file phenomenon.

Comment by Anonymous at 1:16 PM:

df should be reporting 3.8GiB, rather than 3.8GB which is dead-wrong.

Why isn't it?