Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Possible Duplicate:
ext4: How to account for the filesystem space?

I have a ~2TB ext4 USB external disk which is about half full:

$ df 
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdc             1922860848 927384456 897800668  51% /media/big

I'm wondering why the total size (1922860848) isn't the same as Used+Available (1825185124)? From this answer I see that 5% of the disk might be reserved for root, but that would still only take the total used to 1921328166, which is still off. Is it related to some other filesystem overhead?

In case it's relevant, lsof -n | grep deleted shows no deleted files on this disk, and there are no other filesystems mounted inside this one.

Edit: As requested, here's the output of tune2fs -l /dev/sdc

tune2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   big
Last mounted on:          /media/big
Filesystem UUID:          5d9b9f5d-dae7-4221-9096-cbe7dd78924d
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378624
Reserved block count:     24418931
Free blocks:              480665205
Free inodes:              122101749
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Nov 23 14:13:57 2011
Last mount time:          Wed Nov 23 14:14:24 2011
Last write time:          Wed Nov 23 14:14:24 2011
Mount count:              2
Maximum mount count:      20
Last checked:             Wed Nov 23 14:13:57 2011
Check interval:           15552000 (6 months)
Next check after:         Mon May 21 13:13:57 2012
Lifetime writes:          144 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      68e954e4-59b1-4f59-9434-6c636402c3db
Journal backup:           inode blocks
share|improve this question
1  
Someone else will give an authoritative answer, but there is a percentage reserved for administrative/overhead type purposes. –  SpacemanSpiff Nov 29 '11 at 0:02
    
It's off by less than one-tenth of one percent. –  David Schwartz Nov 29 '11 at 0:24
1  
Can you provide the output of tune2fs -l /dev/sdc ? –  Matthew Ife Nov 29 '11 at 0:37
1  
@DavidSchwartz It's still about 1,532,681 KB that's missing (~1.46 GB). That's not a trivial amount of space even if it only accounts for 0.08% of the total. –  Chris S Nov 29 '11 at 0:43
1  
I've added the tune2fs output. I should probably mention it's being written to currently, so the usage numbers in tune2fs might not match the earlier df output. –  Timothy Jones Nov 29 '11 at 0:49
add comment

migrated from serverfault.com Nov 29 '11 at 0:40

This question came from our site for professional system and network administrators.

marked as duplicate by Gilles, Michael Mrozek Dec 2 '11 at 20:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

up vote 11 down vote accepted

Theres no missing space. 5% reserved is rounded down to the nearest significant figure.

1k Blocks: 1922860848

Reserved 1k Blocks: (24418931 * 4) = 97675724

Total blocks used: 927384456 + 897800668 + 97675724 = 1922860848

Edit: Regarding your comment on the difference between df blocks and 'Block Count' blocks.

So the 4k block difference is (1953514496 - 1922860848)/4 = 7663412

The majority of the 'difference' is made up of the "Inode blocks per group" parameter which is 512.

Since there is 32768 blocks per group that puts the number of groups at 488378624 / 32768 which is 14904 rounded down.

Multiplied by the 512 blocks it takes up gives 7630848 blocks.

That gives us 7663412 - 7630848 = 32564 unaccounted for. I assume that those blocks make up your journal size, but not too sure on that one!

share|improve this answer
    
Can you elaborate a bit? Why the multiplication by 4? –  Timothy Jones Nov 29 '11 at 0:54
    
df counts in 1k blocks, but the actual filesystem block size is 4k (see tune2fs Block size), so you need to multiply the reserved block size by four to normalize it to compare with the df output. –  Matthew Ife Nov 29 '11 at 0:56
    
So it is, thanks! Do you know why the total size (488378624 * 4 = 1953514496) is larger than the df total size? –  Timothy Jones Nov 29 '11 at 0:58
    
I edited my previous comment to help explain that for the most part.. –  Matthew Ife Nov 29 '11 at 1:40
    
Excellent, thanks! –  Timothy Jones Nov 29 '11 at 2:47
add comment

If you're using a journaling filesystem (ext3, ext4, etc) the journal will take up space;

share|improve this answer
add comment

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