Red Hat Bugzilla – Bug 444829
[GFS2] df reports 0 bytes used after a >4K file is created
Last modified: 2008-05-27 16:56:03 EDT
Description of problem: Having files larger than one block on a GFS2 fs causes 'df' to report 0 bytes used for the fs. How reproducible: Every time I do the following... Steps to Reproduce: 1. # mkfs.gfs2 -O -j 1 -p lock_nolock /dev/hda5 2. # mount /dev/hda5 /mnt/gfs2 3. # df | grep gfs2 4. Observe 'Used' column is about 130 megabytes 5. Create file /mnt/gfs2/foo and write approx 4000 chars to it (exactly 3865 works for me) 6. # df | grep gfs2 7. Observe 'Used' column is exactly 0 bytes Actual results: - df reports 0 bytes used on the fs: /dev/hda5 1003856 0 1003856 0% /mnt/gfs2 - df keeps reporting 0 bytes used when more files are created Expected results: - df reports 4K more bytes used as another data block is allocated Additional info: This was tested on the latest Linus git kernel today and I bisected it down to commit '[GFS2] Add extent allocation to block allocator' (b45e41d7d56dfef1ae9e02e6c59990066ba82e5c) using 'git bisect -- fs/gfs2' I'm not entirely sure if this helps but adding a printk in gfs2_statfs_change() shows that l_sc->sc_free and free are both -1 immediately after this is executed when the bug occurs: l_sc->sc_free += free;
Ignore that last bit. This is what it should have said: I've added printk's around this line in gfs2_statfs_change(), l_sc->sc_free += free; and now when the bug occurs I get this in dmesg: [ 570.193136] GFS2: Before: l_sc->sc_free = -1, free = 4294967295 [ 570.193146] GFS2: After: l_sc->sc_free = 4294967294, free = 4294967295 So it seems this is due to the cast from positive unsigned int in gfs2_alloc_block() to negative u64 in gfs2_statfs_change(). I made a test case to check: andy@plato:~$ cat bar.c #include <stdio.h> int main(void) { unsigned int n = 1; long long m = -n; printf("Result: %lld\n", m); return 0; } andy@plato:~$ gcc bar.c -o bar andy@plato:~$ ./bar Result: 4294967295
I have sent a patch for this bug to the cluster-devel list. Thanks.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The patch is upstream in Linus' kernel, so will shortly filter back into Fedora.
Commit: ad99f77778e83358c371dab7a50bde69270ed6b8 [GFS2] Fix cast from unsigned int to s64 This bug will only be fixed automatically in rawhide... unless by "filter back into Fedora" you mean when Fedora 9 gets a 2.6.26 kernel.
Yes, thats what I meant. In fact Fedora 9 doesn't have the bug unless it had a kernel of 2.6.25-rc+ anyway, so its not a problem.
The bug was reported against fedora 9, changing to rawhide then.