Re: It's broke, Jim. BTRFS mounted read only after corruption errors on Samsung 980 Pro

[Martin Steigerwald <martin@lichtvoll.de>]

Zygo Blaxell - 05.09.21, 01:38:42 CET:
> Also, regardless of kernel implementation, the hibernation procedure
> is extremely _invasive_.  It necessarily transports every process and
> significant chunks of kernel state to disk and back to memory, and has
> opportunities to corrupt data in transit or at rest.

Well, my hope was that hibernation would be a solved problem. At least 
on ThinkPad T14 AMD Gen 1 it isn't. At least not with the kernel I had 
in use back then.

I did not dare to test again, nowadays running 5.17-rc3. Cause if the 
price for a while test is corruption of BTRFS, I do not really look 
forward to it.

The only laptop where hibernation really works without any issues I 
currently have is a ThinkPad T520 (Intel Sandybridge). It also works on 
X260 and T560. However there starting with kernel 5.16 it does not 
automatically switch off after writing the hibernation image. With 5.15 
and prior it switched off except after the initial boot. It switched off 
automatically on the second hibernation cycle.

> > > Start a memory tester running (e.g. 'memtester' or '7z b 9999
> > > -md=xxM' where xx is large enough to allocate most of the free
> > > RAM), do hibernation and resume, and see if the memory tester
> > > reports failure after resume.
> > 
> > I may still do this. However I already run the UEFI Lenovo
> > Diagnostic
> > tool and had it do a memory test. It appears to be fine. I did the
> > quick test but then also ran a good part, but not all of a several
> > hour long test. No issues.
> 
> The environment might be different for a stand-alone memory tester
> compared to one that can run on Linux alongside a production workload.
> e.g. if a bus component is failing due to heat stress, that failure
> might not be triggered in the standalone case where the failing bus
> componenet is inactive, but will be triggered under a full system
> load where the failing component is active.  Similarly bugs in the
> Linux kernel itself, or interactions between kernel and firmware,
> will not be visible with a standalone test.
> 
> On the other hand, if the problem _is_ a RAM component failure, a
> standalone test will verify it's that and nothing else.

What I can say so far:

If I avoid hibernation, then all is fine. Starting with kernel 5.16 the 
Windows based deeper standby that usually worked with 5.15 and prior 
does not reliably work anymore, so I switched the BIOS back to using the 
one for Linux again.

Really would love to use hibernation again, but so it is.

At least I am pretty confident it is no BTRFS issue, cause I had no 
corruption issue again after avoiding hibernation. And hibernation with 
BTRFS works just fine on T520.

Best,
-- 
Martin