On 2021/2/20 下午8:07, chainofflowers wrote:

On 20.02.21 12:46, Forza wrote:

quoted

Are you using fstrim by any chance? Could the problem be related to
https://patchwork.kernel.org/project/fstests/patch/20200730121735.55389-1-wqu@suse.com/

Yes, that's what I mentioned in my first post.
Actually, it all started with the bug with dm, but some similar
behaviour persists even after that bug was fixed:
https://lore.kernel.org/linux-btrfs/20190521190023.GA68070@glet/T/ (local)

The only "maybe unusual" thing in my setup is that I use btrfs on the
top of dmcrypt directly, without lvm in-between, but I am not the only
one...

@Qu:
My RAM looks OK so far, I also thought of that, and I actually ran
memtest for 12+ hours and more than once. I would exclude that case.

I will do a "btrfs check --check-data-csum" and let you know.

In the meantime, I thought of a related question:
-> When a data-csum is corrupted (for whatever reason), is there a
chance that the corruption persists when I copy the whole file system
over to a new one?

You can rule out the possibility that some data checksum itself is
corrupted.
Data checksum is stored in btrfs trees, and all tree blocks have their
own checksum.

As I said previously, I copied the whole fs to new, virgin SSDs more
than once with "rsync -avAHX", and I couldn't spot any issue related to
the copy itself...

Then you can rule out the checksum problem.

Thanks,
Qu

(please help! ;-))

(c)