@golinux please close this, I have not filed any "official" bug reports and don't intend to. Better yet just delete it as nobody else seems to be able to reproduce which means it must be a local fault.

Also boot a live system and run fsck -N against the filesystem. That should check for discrepancies without updating anything.

But please *don't* just reply "done that" without any details of what happened. Output that seems insignificant to you may be *very* interesting to  us.

Utils such as df, just read this metadata, so I would suggest that you're barking up the wrong tree. The metadata  won't have changed between boots/kernels.

So far all of your responses have been "already done that" with no real specifics. The big question is : Booting from that 6.1.176 kernel apparently frees up 400MB which is then lost when reverting to the previous 6.1.174 kernel. But how are you doing that? You need both kernels installed simultaneously. Then you need to reboot into each and check. If you're doing any package management operations between each boot, this obscures your results.

Does booting from any newer kernel also free up this same amount of space? Does the latest stable kernel give the same result? Does the latest 6.1.177 kernel also apparently free up 400MB.

In all tests, are you booting single user mode and comparing all results there?

Have you compared the sizes or kernel image, initrd, kernel modules for each?

So whatever re-wrote that metadata that Ralph mentioned, must have written it wrong, if it's not the kernel that writes it, then what does?

I just don't have any more time to keep installing the same system and doing the same updates to it and doing the same tests over and over and getting the same results, maybe it's not the kernel, but it's something, I just don't have time to track it down any further. I've posted what i know and now I need to move on as I have a lot of irons in the fire.

Also does df -i show significantly different results.

If the answer to the first question is yes then you *might* have a bug worth reporting. But please post output from dumpe2fs -h in the two cases first.

Blackhole -  Already done that too. "drama", lol, that's too rich coming from you.

Did all that last night into the wee hours of the morning. Not sure what it takes to convince y'all that I have quadruple checked and tested in multiple ways. It's simply a fact that it's 2.7 gb in size, not 2.3 gb. df is reporting wrong and so is dumpe2fs for whatever reason.

But if the concensus is that it's not an issue then I won't bother reporting it. I'll wait on updates until the next kernel update and see what happens then.

If you were to report a bug, those are the kind of steps which would be expected as a bare minimum.

That should tell you if it's the software or it was the disk contents that changed.

If you want to be really sure mount a third partition read-only on both partitions and compare what they say about it.

I'd also compare df -h with df -k and df -i in all cases (the more data you have the better).

I find it hard to believe that it was previously reporting incorrect sizes for the last 2 years and somehow just now corrected that, I did briefly consider that.

There's no way those packages that got updated are 400 mb less than their predecessors. And still I am left with the fact that some methods are reporting 2.3 gb, and others are reporting 2.7 gb. And the two different isos ran from those systems are identical in size.

If the kernel didn't create that data that df is referencing, then what does create it?

Just trying to get some data here before I run through the whole process of re-installing the earlier version then doing the updates for a third time. I haven't filed a bug report yet because I want to be thorough about it. But if this is indeed a bug, it could be bad if a user is maxing out their disk space but being told they have room yet, this is why I couldn't just let it slide, if it happened to you would you not go to some effort to find out why and maybe warn folks?

Perhaps the different kernel package and those that go with it have that smaller footprint, to thus result in the smaller figure. Or sometimes one may forget about cached and trashed files as well as log files in a setup, which would typically result in a larger figure than it could be. If the difference is due to some mistake like that or whatever way, then it's just a mistake. Otherwise there  obviously is a significant aggregated difference in those software collections after installations.

There is also that possibility that the different reporting programs take measures into account the previously weren't included, though I would believe the newer method as more accurate and thus think "less bad" about them, rather than calling them "bad" for computing differently.

So you're suggesting all those reporting tools went bad at once somehow? I'm open to suggestion here Ralph, but that seems a little implausible, what on that list of upgrades do you suppose might have caused it if not the kernel?

blackhole:

I can say and I don't need to speculate, I provided a list of them above, did you read it before you posted this?

I have the exact same system sitting on the partition next to it using the older kernel, not sure what more gems of assumption you have laying around, but they're not helping.

The kernel doesn't report disk usage. All raw figures are in filesystem meta data

That's the thing, the superblock where that metadata is stored is reporting wrong seemingly. And calculating wrong, and reporting wrong. Have tried dumpe2fs and stat, and they're not reporting anything more than what's been written in that metadata, which is wrong. The kernel is doing this.