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 byat 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 byat 1:16 PM:
df should be reporting 3.8GiB, rather than 3.8GB which is dead-wrong.
Why isn't it?