Bug 444829 - [GFS2] df reports 0 bytes used after a >4K file is created
[GFS2] df reports 0 bytes used after a >4K file is created
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Whitehouse
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-04-30 17:10 EDT by Andrew Price
Modified: 2008-05-27 16:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 10:44:30 EDT
Type: ---
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 Andrew Price 2008-04-30 17:10:06 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;
Comment 1 Andrew Price 2008-05-01 06:16:01 EDT
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
Comment 2 Andrew Price 2008-05-01 06:58:20 EDT
I have sent a patch for this bug to the cluster-devel list. Thanks.
Comment 3 Bug Zapper 2008-05-14 06:26:49 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 4 Steve Whitehouse 2008-05-21 10:44:30 EDT
The patch is upstream in Linus' kernel, so will shortly filter back into Fedora.
Comment 5 Chuck Ebbert 2008-05-27 12:13:07 EDT
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.
Comment 6 Steve Whitehouse 2008-05-27 12:22:45 EDT
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.
Comment 7 Chuck Ebbert 2008-05-27 16:56:03 EDT
The bug was reported against fedora 9, changing to rawhide then.

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