Red Hat Bugzilla – Bug 231239
GFS2: statfs code clean-up
Last modified: 2010-01-11 22:37:30 EST
Description of problem:
In the middle of porting GFS2 fast statfs implementation back into
GFS1. While working thru the code, there are obvious issues found
in the existing GFS2 code. Open this bugzilla to track them so it
won't get lost.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
* GFS2 stores statfs statistics info in two files. Upon node crash,
the data left behind in page cache could get lost (?). Can't find
the logic where these data can be recovered. Need to look into this.
* There is a "slow" path statfs call (identical to GFS1 behavior) but
doesn't seem to have external interfaces to invoke it (?). With the
above recovery issue, we may need this slow path to re-calculate
the disk utilization data and correct the master file accordingly.
* The fields in struct gfs_statfs_change_host is defined as __u64
(unsigned long long) but is used as s64 (signed long long) thru out
the code. Not sure how compiler handles this but some of the math
looks very wrong to me (gfs2_statfs_i(), for example).
* There are probably more - will update the bugzilla when I find them.
* Some of the fields in struct kstatfs (buf) is not properly set in
This is not a problem (maybe it is ?) but can well describe the difficult
aspect of this approach. The statfs per node delta is synced to master
file every 30 (default) seconds. This implies if anyone floods huge amount
of data into GFS2 partitions quickly from one node, the "df" output from
other node will be far-off from the actual value. We need to improve this
a little bit (say if the delta is above 10%, it should get unconditionally
I must admit that I thought that it was using the same algorithm as the quota
system of increasing the frequency of syncing as we near the limit. Have you
come to any conclusions about what needs to be done in GFS2 yet?
Probably the reason that statfs_change_host has a __u64 is that it was copied
directly from the statfs_change on-disk structure which would be a __be64 and
thus sign isn't really taken into account. So long as all the manipulations
are done using the s64, then there should be no problem. It is a long term goal
to rid ourselves of the _host structures, and I think that should be trivial in
this case just by passing the struct kstatfs to gfs2_statfs_slow and
I presume the two fields you are referring to in comment #2 are f_fsid and
Not sure how RHEL5 compiler handles this - but on RHEL4, I got funny data.
When blocks count should be subtracted, it immediately becomes a huge number
(apparently the compiler does an "add-using-unsigned", instead of two signed
long long math). However, it is possible that I have header file issues
And yes, the f_frsize, etc are not initialized.
These are not critical issues - so don't worry about them. Will fix them
when I'm done with RHEl4 port (and using the same test suites to unit test