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.
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.)
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 ...
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.
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.