Re: df command reports incorrect usage

[Bob Proulx]

Rob Landley wrote:
> Fariya F wrote:
> > The version of df command is 1.85.

A current version of Coreutils df by most distros would be 8.x and the
upstream stable version is version 9.  This leads me to believe that
the df you are using is not from Coreutils but from somewhere else.
But not Busybox because that would only be up to version 1.35 so far.
In any case it seems that you are not using the GNU Coreutils df
program at all here.

I am so very curious as to what system this is on.  And wondering if
it is an embedded system.

> > Kernel version 4.9.31
>
> A 2016 release, plus bugfixes.

Yes.  But I think unlikely to the be problem here.  If we were in 2016
ourselves right now then we would be looking at that and seeing that
it was as up to date as it was possible to be at that time.  The
kernel had been dealing with file systems, ext4, and SD cards for
decades already by 2016.

> > 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.
...
> Probably fixed in one of the thousand-plus commits to fs/ext4 since then. I'd

I think more likely that the SD card image is corrupted.  Which would
mean that even the newest kernel today would report the same information.

> 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?

It was reported to be 100MB ext4 in size with only 5.8MB used.  Really
very small.  And the root cause of the problem I think will be
isolated to the file system superblocks.  So actually smaller.  You
could probably completely debug the problem top to bottom.

> > How can we get this corrected and where is the corruption because
> > of which this value goes wrong?

If it's only 5.8MB of used data according to du then here is what I
would do to recover from this problem.  I would copy all of the data
off of this ext4 file system to a backup location.  That's very small
these days.  I would make a complete backup copy.  And since I suspect
there is other data on other partitions of this SD card I would also
backup ALL of the data on this card and not just this partition.

And if that backup copy works then I would count yourself lucky.
Because it might not work.  Actually trying to copy the files off
might uncover where one of the file chains is corrupted.  However you
had also reported that fsck had been successfully run on it.
Therefore I think it likely that you will be able to copy all of the
files off of this SD card and make a successful backup.

Then I myself would throw the SD card away!  Since it is likely bad.
And in a 32GB size card right now we are talking about USD$14 or so.
Replace it with a new one since that is inexpensive.  However you say
this partition is only 100MB.  Which implies to me that this is one
part of the larger SD card.  Is that right?

If it were me then after making a complete backup of ALL files then I
would run badblocks with the destructive -w option (read the
documentation as it is a DESTRUCTIVE TEST) on the partition and check
to see if the card hardware is functional or not.  If that fails then
obviously the hardware has failed.  If that succeeds then I would
think the image had just gotten corrupted.  In which case the file
system could be rebuilt.  And having been rebuilt the new bits would
be correctly constructed and the problem solved.

If it is not a hardware failure and you really want to use this SD
card then after ensuring that I had a FULL BACKUP I would then wipe
the file system signatures off of the partition with "wipefs -a" and
then rebuild the file system on it with "mkfs -t ext4".  Then mount
the file system and copy back the data from the backup copy that was
made.  That recipe would create a new file system fresh on it and that
would fix the bad data in the file system superblocks.

So far there has been no mention if this is a bootable image or not.
If so then it may be necessary to restore an MBR boot record.

Bob