Bug 1013741 - df is incorrectly reporting free space
df is incorrectly reporting free space
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-09-30 12:59 EDT by cornel panceac
Modified: 2013-12-19 15:46 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-19 01:53:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description cornel panceac 2013-09-30 12:59:02 EDT
Description of problem:

'df' reports no free space left when the ammount of available space is greater than the used space and inodes are far from being used up.

Version-Release number of selected component (if applicable):

$ rpm -qf /usr/bin/df

How reproducible:

Steps to Reproduce:
1.set reserved blocks on filesystem to 0%
2.write files on disk

Actual results:
disk is reported as full even if there"s space left:

$ df -h /home
Sistem de fișiere Dimens Utilizat Liber  Uz% Montat pe
/dev/sda11          274G     271G  669M 100% /home

$ df -i /home
Sistem de fișiere  Inoduri IUtilizat   ILiber IUz% Montat pe
/dev/sda11        18243584    305057 17938527   2% /home

Expected results:

3GB of space free

Additional info:

$ sudo tune2fs -l /dev/sda11
tune2fs 1.42.7 (21-Jan-2013)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          7eb34dca-e57c-40af-b08e-d795e1921fbb
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:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              18243584
Block count:              72942848
Reserved block count:     729428
Free blocks:              905230
Free inodes:              17938556
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1006
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Jul  7 00:02:10 2013
Last mount time:          Mon Sep 30 18:55:44 2013
Last write time:          Mon Sep 30 18:55:44 2013
Mount count:              270
Maximum mount count:      -1
Last checked:             Sun Jul  7 00:02:10 2013
Check interval:           0 (<none>)
Lifetime writes:          388 GB
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
First orphan inode:       11012977
Default directory hash:   half_md4
Directory Hash Seed:      ee2d7413-bf9f-4b6d-bca1-674b47ab60a1
Journal backup:           inode blocks

This seems to cause different applications (like transmission-gtk) to work incorrectly when the disk appears to be full.
Comment 1 cornel panceac 2013-12-19 00:54:09 EST
this is still happening on fedora 20. 

$ rpm -qf /usr/bin/df

other info: if i delete ~ 100 MB of files, both before and after running sync, i get back 30 MB of files.

This particular issue gets fixed after rebooting the machine (probably due to remounting the file system.)
Comment 2 Ondrej Vasik 2013-12-19 01:53:43 EST
Why do you think you should have 3G of free space? Size - Used != Available ... as to other info - you mean if you delete 100MB of files, you'll get 30MB of available free space, right?
I still see Reserved block count: 729428 in your setup - in your tune2fs output - which is reserved only for root. With 4096 bytes per block, it's perfect match to 3G ... maybe you need to remount the disk to get the 0 reserved blocks active? This would explain the reboot "fix". Anyway - it doesn't sound like df issue - for me NOTABUG. Btw. similar thing is part of coreutils FAQ - http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#df-Size-and-Used-and-Available-do-not-add-up ...
Comment 3 cornel panceac 2013-12-19 03:09:39 EST
well, this is interesting, since as i've said, i"ve used tune2fs to set the reserved space to 0. gonna verify at home and provide feedback.
Comment 4 cornel panceac 2013-12-19 15:46:56 EST
so, back home, i've ran tune2fs -m 0 on two partitions, with different sizes. after, the reserved block count became instantly 0 (this is on f20 x64). Adding used and free, and comparing with total, i got a difference of 16384 1K blocks on both partitions. This is an acceptable loss for partitions at least 20 GB in size. As for the other issue, i'll create a new ticket, if it proves to be indeed a problem. thank you.

Note You need to log in before you can comment on or make changes to this bug.