Bug 1013741

Summary:	df is incorrectly reporting free space
Product:	[Fedora] Fedora	Reporter:	cornel panceac <cpanceac>
Component:	coreutils	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	admiller, kdudka, kzak, ooprala, ovasik, p, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-19 06:53:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description cornel panceac 2013-09-30 16:59:02 UTC

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
coreutils-8.21-11.fc19.i686



How reproducible:
always

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

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 05:54:09 UTC

this is still happening on fedora 20. 

$ rpm -qf /usr/bin/df
coreutils-8.21-18.fc20.x86_64

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 06:53:43 UTC

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 08:09:39 UTC

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 20:46:56 UTC

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.