Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

While creating a 250GiB backup partition for my data, I have noticed lots of discrepancies between reported partition size and free space in Nautilus, gParted, df, tune2fs, etc.

At first I thought it was a GiB / GB confusion. It was not.

Then I thought it could be ext4's reserved blocks. It was not.

Im completely puzzled. Here are some images. Here are the steps:

  • First, NTFS. 524288000 sectors x 512 bytes/sector = 268435456000 bytes = 268.4 GB = 250 GiB.

enter image description here enter image description here

Nautilus say "Total Capacity: 250.0 GB" (even though its actually GiB, not GB). Apart from that minor mislabeling, so far, so good

  • Now, same partition, formated as ext4 with gparted:

enter image description here

First, Last and Total sectors are the same. It IS the same 250GiB partition. Used size is 4.11GiB (reserved blocks maybe?)

enter image description here

Nope. Looks like reserved blocks are 12.7 GiB (~5%. ouch!). But... why Total Capacity is now only 246.1 GiB ???. That difference (sort of) matches the 4.11 GiB reported by gparted. But... if its not from reserved blocks, what is it? And why gparted didnt report that 12.7GiB of used space?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

df matches Nautilus in reported free space. But.. only 188M used? Shouldnt it be ~12GB? And total capacity is still wrong. So i ran tune2fs to find some clues. (irrelevant output is ommited)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 total blocks * 4096 bytes/block = 268435456000 bytes = 268.4 GB = 250 GiB. It matches gparted.

3276800 reserved blocks = 13421772800 bytes = 13.4 GB = 12.5 GiB. It (again, sort of) matches Nautilus.

64459851 free blocks = 264027549696 bytes = 264.0 GB = 245.9 GiB. Why? Shouldnt it be either 250-12.5 = 237.5 (or 250-(12.5+4.11)=~233) ?

Removing reserved blocks:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

As expected, same block count, 0 reserved blocks, but... same free blocks? Didnt I just freed 12.5 GiB ?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

enter image description here

Looks like I did. Avaliable space went up from 233 to 245.9 GiB. gparted didnt care at all, showing exactly same info! (useless to post an identical screenshot)

What a huge mess!

I tried to document it as best as I could... So, please can someone give me any clue on what's going on here?

  • What are those misterious 4.11 GiB missing from NTFS -> ext4 formatting?
  • Why there are so many discrepancies between gparted, Nautilus, tune2fs, df?
  • What is wrong with my math? (questions in bold scattered this post)

Any help is appreciated. While I can not figure what is going on, I am serilously considering giving up on ext4 in favor of NTFS for everything but my / partition.

Thanks!

share|improve this question
    
    
    
@Uri Herrera: did you actually read my question, or at least the first few lines? This is not a GiB/GB issue. Partition is 268.4GB = 250.0GiB, not 246.1 –  MestreLion Jun 13 '11 at 11:35
1  
Another answer you can take a look at: askubuntu.com/questions/5335/… –  enzotib Jun 13 '11 at 13:04
1  
See also ext4: How to account for the filesystem space? –  Gilles Nov 20 '12 at 19:15
add comment

3 Answers 3

up vote 6 down vote accepted

There are a few things going on here. gparted reports the actual used/free space. The kernel reduces the available count by the reserved space. After you removed the reserved space, the free count did not change because the reserved blocks already were free; it is just that non root users are not allowed to invade that space to prevent them from causing trouble by filling up the disk. The gnome numbers are a little flaky because of a bug. Instead of reporting the used space that the kernel reports ( and df shows ), it computes it by subtracting the free space from the total. This causes it to show reserved space as used.

The missing 4GB is actually used is the fs overhead for ext4. NTFS only initially allocates a small amount of space for the MFT, and grows it as needed. The ext series of filesystems though, allocate space for the inode table ( rough equivalent of the MFT ) at format time and it can not grow. The space missing from the reported total space is the inode table. The remaining bit of used space is from the journal ( usually 128 mb ) and resize inodes.

share|improve this answer
    
Thanks, +1 for solving some of the mysteries! But, if the ~4GB are filesystem overhead, why some of it (3.9GB) is deducted from total space, while 188MB is showing as actually used? Which (or both) is the overhead? And why handled differently? Also, df, even with sudo, shows total capacity (247GB) and used space (188MB) like Nautilus. So if its a bug, its not only gnome's. –  MestreLion Jun 13 '11 at 19:55
    
I thought the 188MB was the overhead (as compared to the 72MB from NTFS). But, if NTFS overhead will grow after time, does that mean Nautilus would later report it's total capacity shrinking? –  MestreLion Jun 13 '11 at 19:59
    
Correction: df always shows available space, no matter who runs it. To see the free space (== available space + reserved space), use stat -f /media/BACKUP. –  Marius Gedminas Jun 13 '11 at 21:19
    
Edited answer to clarify. And I believe that NTFS will just report more used space, not shrink total as the MFT grows. @Marius, this is not correct either. statfs() and hence both df and stat -f both show the available space not counting the reserved blocks. I could have sworn that it also adjusted for quota, and varied its response based on the calling user, but you are right about that; it does not count quota and does not care what user calls it. –  psusi Jun 14 '11 at 1:41
    
@psusi: so I have ~3.9GiB of inode table, and ~188MB of journal+something? And Nautilus subtract inode table from Total Size, while reports journal as used space? And gparted reports them as a single 4.11GiB of used space? Is that correct? If so, i just wished Nautilus handled both overhead the same way.. either both subtracted from total or both counted as "used space" (preferably). –  MestreLion Jun 14 '11 at 16:58
show 1 more comment

First of all, reserved blocks are not block used for filesystem internal management.

Reserved blocks are simply reserved for root, as to assure that services using files on that partition cannot be ruled out of space by some non-admin user filling all the space.

Even with no reserved blocks (-m 0) there is always a part of the space used for filesystem internal management, I cannot say how much, I have not such a deep knowledge.

Also, Gparted is executed as root, so it see reserved blocks as free. Nautilus, executed as user, see them as non free.

Ok, @psusi answer is very clear, I have nothing to add.

share|improve this answer
    
Humm, very informative, +1. At least this solves some of the issues I've found. Seeing reserved blocks as a "limit cap" for non-root instead of "used blocks" makes gparted, df and tune2fs readings agree (and make sense). But some questions still remain, specially the 4GB of used space / total capacity. –  MestreLion Jun 13 '11 at 19:28
1  
Also, I've read somewhere (one of those old "why you don't need to defrag your Linux partition every month" HOWTOs perhaps?) that reserving 5% space for root gives some breathing space to the extN allocation algorithms and therefore avoids fragmentation. –  Marius Gedminas Jun 13 '11 at 21:22
add comment

Try reducing the partition size by a few megabytes using gparted, then increasing it again to its original size. This may cause other applications to read the sizes correctly. I recently corrected a 50Gb error this way!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.