Re: Massive filesystem corruption since kernel 5.2 (ARCH)

[Chris Murphy <lists@colorremedies.com>]

On Mon, Jul 29, 2019 at 8:40 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2019/7/29 下午10:34, Swâmi Petaramesh wrote:
> > Le 29/07/2019 à 16:27, Qu Wenruo a écrit :
> >> BTW, I'm more interesting in your other corrupted leaf report other than
> >> this transid error.
> >
> > Well I already broke 2 FSes including my most important computer with
> > this, took me 2 working days to restore and mostly fix my main computer
> > which I couldn't use for a week (because of lack of time for restoring
> > it) and now I lose my main backup disk.
>
> At least from what I see in this transid error, unless you ruled out the
> possibility of bad disk firmware and LVM/LUKS, it's hard to say it's
> btrfs causing the problem.

I'm using kernel 5.2.x since early rc's on several ystems, nvme, SSD,
HDD, half plain partition, half on dmcrypt/LUKS. I can report no
problems. None are on LVM.

It comes down to:
a. workload specific behavior is triggering a new bug in Btrfs or dm
or blk layer, or combination
b. new hardware issue

It seems to me whenever weird stuff pops up with ext4 or XFS, their
call traces generally expose the problem, so I wonder if Btrfs devs
still have the kernel debug information needed to point the blame; or
if there needs to be some debug mode (mount option?) that does extra
checks to try and catch the problem. Is this a case for metadata
integrity checking of some kind, and have Swâmi run this workload?
Either on the problem file system or a new Btrfs file system, just to
gather better quality information?

But yeah, at least a complete current dmesg is needed. And even
possibly helpful is kernel messages for the entire time since
switching to 5.2.0: it could be a big file but easy to filter for dm,
libata, smartd, and btrfs messages. The filtering I'd leave up to a
developer, I always by default provide the entire dmesg, it's not
always clear what the instigator is.

We've discussed many times how both file system repair, and file
system restore from backup, simply are not scalable for big file
systems. It takes too long.


-- 
Chris Murphy