What size is my disk/data really?
 

I have a 200GB SATA drive divided into 2 equal partitions.
According to GParted, both partitions are 93,1GB. HOWEVER, according to the System Monitor (I'm using Gnome 2.14.3) the first partition is only 50.4GB

On the first of the partitions I store my music files. According to DU I have 42GB of files on the drive.

When I right-click on the mountpoint for the partition in Nautilus and look at the properties I also get that information, BUT it also informs me that I have 6.2GB of free space. 93.1GB - 42GB = 6.2GB??? That doesn't add up. What is going wrong (or what am I missing? Where did the other +40GB go?

Done a filesystem check on them ???.
What about the inode usage ???.

I think there are two main factors. The first is that to an engineer, one kilobyte = 1,024 bytes, but to a marketing person, one kilobyte = 1000 bytes, and guess who decides how to label the box. Scale that up to a meg or a gig, and all those 24 byte differences start to add up. Your 200G drive does contain 200G of writable space, but it's equal to the scientific definition of 200G. Secondly, root reserves part of the space for its own use, just in case. (IIRC, it's about 4%-5%) The idea behind the reserved space is to act as a buffer against any possible runaway "write" processes that could fill up the drive. If there literally was no space on drive, then the computer couldn't boot because it would not be able to write anything to the disk.

Actually the prefixes "kilo", "giga", "mega" etc. are very well established in math and science circles as orders of 10. To say that a kilo is 1024 is incorrect - the proper term is "kibi" as proposed by the International Electrotechnical Commission (IEC) (likewise "gibi", "mebi"). The marketing people actually got it right this time.

Anyway, I would recommend opening up a terminal and running the "df" command. Also I don't know about Nautilus but Konqueror has excellent disk usage view modes - you might consider checking it out as well.

Yes, but No. While the prefix "kilo" means "thousand", in this context I believe my response remains accurate. Computers are binary systems, and in the context of a binary system, "kilobyte" means 1024, or more specifically, 2^10 bytes. The "kibi" term you mention perhaps is helpful in distinguishing between the two definitions, but I think its weakness is that it's only a proposed standard, and it's not widely used. Assuming that the Wikipedia entry is considered valid and factual, readers can form their own opinions.

This bickering isn't going to help the OP - how about you leave it folks, it's been done to death enough times.
Nor does it explain a better than 40% discrepancy observed - regardless of the base used to derive the math.

Who's bickering? The different reporting mechanisms for disk size are certainly relevant to the discussion, as they do play some factor. If the OP happens to learn something more than they asked for then all the better.

As for this discussion being done to death, if you search linuxquestions for "gibi mebi kibi" you'll see how often it's been raised here.

Finally, since I don't take "shush" posts well, here's a link to another wikipedia entry that some may find interesting:
http://en.wikipedia.org/wiki/Binary_prefix

I'm looking into fschk (never used it before), but I'm not sure about what exactly you mean by 'inode usage'. I seem to remember that files don't necessarily take up the space they need, but rather the nearest approximate space depending in the ?? of the filesystem (like 32 in fat32). However, that doesn't look like it might be the case, as the average filesize is around 3MB and if I remember correctly what I described would be especially noticeable with very small files.

J.W., Ciotog: I appreciate the explanations - I was aware of the fact and the relatively small difference between the label of the drive (200GB) and the actual partition sizes as reported by GParted (2x93.1GB) was expected.
The problem I described only refers to the first partition, as the second reports its space correctly. It even reports more space than ought to be possible: 90GB used, 11GB free.

The question was not 'where did the 3-4% go, but what happened to the 40% that appears to be missing

P.S.
The number of blocks would (almost) add up to 200GB using a 1000 base (instead of 1024) and part of the missing 3% would have been lost creating partitions. Also there is the MBR...

Surely it's just a plot to reserve just enough space to install MS Windows Vista on your harddisk in the dark hours of the night when you're not aware and those creepy MS engineers crawl from under your bed to poison the computer...

..or not :) Anyway, is it possible that you took the harddisk and inserted it onto another computer as a slave, with another OS than yours on board, and see if that counts the space the same way? Maybe too big a trick to do, but if you're out of ideas, it doesn't harm to try..

"df -i" - chack there aren't any suspect numbers.

I ran e2fsck (output below) but there's no change in the free space / used space nautilus sees


P.S After reading man fsck I found out I should unmount the partition before running e2fsck. THat makes it a littel difficult to make it an automated task... or does it?

fsck for ext2/ext3 filesystems usually runs automatically on mount, every 20 mounts or so (this can be changed using the tune2fs program). If you wanted to force a fsck on every mount, you would run "tune2fs -c 0 /dev/sda1".

To see the number of blocks marked bad, you should run "dumpe2fs -b /dev/sda1"

Also as has already been suggested twice, you might wish to see the output of "df" or "df -i" (note that df has an option -si so that it follows the correct standard of using powers of 10 ;) ). Also try running Konqueror, and browse the filesystem using the view -> "View Mode" -> "File Size Mode" to see if there are any unusually large directories (like tmp) that are somehow consuming lots of space but aren't being reported correctly.

Why would df think the partition is only 50GB when fsdisk reports 93GB?

Suddenly all sorts of alarms are going off in the back of my head! The partition used to be 50BG and I used QTparted from knoppix to stretch it to 50% of the HDD. I suppose somehow the ext3 file system wasn't extended properly to cover all of the new partition size. That means I need to recreate the ext3 file system, but without destroying the data that's already on the disk, or making it inaccessible by overwriting the 'index' (is thet the inode table? - I appear to remember something like that.)

How would I go about doing that?

That doesn't appear to be a valid option....

mkfs appears to be destructive (with respect to the existing data)...

Arrrrhhhh !!!!
I hate it when people with-hold important information. This is hardly "oh, by the way ..."
You're the one wanting help here - are we all expected to be bloody mind-readers ???.

Look up ext2resize on sourceforge.
Take note of my signature.