Yes it is an embedded system. The package we have used is coreutils 8.25
and not 1.35. Very sorry for the confusion.
On Tue, 22 Mar, 2022, 10:43 pm Bob Proulx, <b...@proulx.com> wrote:
> 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
>
