Re: df command reports incorrect usage

[Fariya F]

This is a 32 bit hardware. This partition has private data in here.


Regards
Fariya

On Tue, 22 Mar, 2022, 8:48 pm Rob Landley, <rob@landley.net> wrote:

> On 3/22/22 9:12 AM, Fariya F wrote:
> > Hi,
> >
> > The version of df command is 1.85.
> > Kernel version 4.9.31
>
> A 2016 release, plus bugfixes.
>
> $ git log --no-merges v4.9..master fs/ext4 | grep ^commit | wc -l
> 1213
>
> Bit of water under that bridge in the past 8 years.
>
> > The fsck check on that partition succeeds. I am able to use the
> partition,
> > create files etc. However df reports incorrectly the size and used
> > percentage.
> >
> > Output from strace command is as follows;
> >
> > statfs64("/data", 88, {f_type="EXT2_SUPER_MAGIC",
> > f_bsize=1024, f_blocks=18446744073659310077, f_bfree=87628,
> f_bavail=80460,
> > f_files=25688, f_ffree=25189, f_fsid={-1446355608, 1063639410},
> > f_namelen=255, f_frsize=1024, f_flags=4128}) = 0
> >
> > As can be seen, value of f_blocks is a huge one. How can we get this
> > corrected and where is the corruption because of which this value goes
> > wrong?
>
> In the kernel's ext4 driver. 0xfffffffffd015ffdL looks like a negative
> number
> mapped to positive (around -50241539). Possibly something returned an error
> value that didn't get checked, or there was an underflow, or...?
>
> Is this 32 bit hardware? That gets less testing these days than 64 bit
> does,
> could be a "long" where a "long long" is needed? (In the ext4 driver.)
>
> Probably fixed in one of the thousand-plus commits to fs/ext4 since then.
> I'd
> start with:
>
> $ git log --no-merges v4.9..master fs/ext4 | egrep '(over|under)flow' | wc
> -l
> 40
>
> But it could also be "error return used as a result" which is "track it
> down
> with a bunch of printk()" territory for me.
>
> Another thing you could do is copy your image to file (cat /dev/sdx >
> file.img)
> and use a VM image to read it (I use
> https://landley.net/toybox/faq.html#mkroot
> for this sort of thing) and then see if current kernels can read it
> properly (if
> not, report it to lkml), and if it WAS fixed git bisect between v4.9 and
> master
> to find the commit that fixed it. (Remember the bad-is-good swap in that
> case.)
>
> Hmmm, I'm making tutorial videos now... How big is this storage device,
> and does
> it have anything private on it?
>
> Rob
>