Re: Mysterious disappearing corruption and how to diagnose

[Andy Smith <andy@strugglers.net>]

Hi Qu,

On Sat, Aug 30, 2025 at 09:33:49AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2025/8/30 09:18, Andy Smith 写道:
> > Hi Qu,
> > 
> > On Sat, Aug 30, 2025 at 08:28:25AM +0930, Qu Wenruo wrote:
> > > 在 2025/8/30 07:47, Andy Smith 写道:
> > > > Okay. Yes it is still supported by Debian so they are still publishing
> > > > updates for the related LTS kernel but I am relying here on fixes going
> > > > in to LTS kernel in the first place.
> > > 
> > > In v6.4 we reworked the scrub code (and of course introduced some
> > > regression), but overall it should make the error reporting more consistent.
> > > 
> > > I didn't remember the old behavior, but the newer behavior will still report
> > > errors on recoverable errors.
> > > 
> > > I know you have ran scrub and it should have fixed all the missing writes,
> > > but mind to use some liveUSB or newer LTS kernel (6.12 recommended) and
> > > re-run the scrub to see if any error reported?
> > 
> > I do a bit of travelling the next few days and I will not like to change
> > kernels on this non-server-grade system with no out-of-band management
> > while I am not close by. So, I will leave things with sdh outside of the
> > filesystem for now.
> 
> Have a good travel.
> 
> > 
> > When I return I will upgrade the kernel, scrub and if clean put sdh back
> > into the filesystem then scrub again. The Debian bookworm-backports
> > repository has a linux-image-amd64 package at version 6.12.38-1~bpo12+1.
> > 
> > When I go to put sdh back in to the filesystem, I can do so with a
> > "replace" because sdh > sdg. Unless you think it would be better in some
> > way to do a "remove" and then an "add" this time?
> 
> Replace is way more efficient/faster than remove then add.
> 
> The latter will relocate all chunks of the source device to other devices
> (which may not even have enough space), and add the new device empty.
> Thus you will need to rebalance all those chunks again to reach the new
> device.
> 
> So just plain dev-replace will be the best.

Just to close this off in a slightly unsatisfactory way:

I found time this last few days to upgrade the machine to Debian 13, so
that is kernel 6.12.48+deb13 and btrfs-progs v6.14.

I did a scrub in the state that it was when we last corresponded
(suspect SSD not in the filesystem) and that came back all clean.

I did a replace to get the temporary drive out and the suspect SSD back
in, which went without incident.

Then I did a scrub again and again all was fine.

So I now can't see any problem. I can't reproduce what was happening
before.

Thanks,
Andy