False alarm, not a new issue at all! I have a different system on kernel 5.1.11 using Btrfs as root with persistent systemd-journald storage, and compress=zstd. And I never have problems with it, so I never run btrfs check on it, until now. And yep, same problem. All the journals that have been rotated, are zstd compressed, are nocow, and btrfs check complains about them the same way.
root 257 inode 62526 errors 1040, bad file extent, some csum missing root 257 inode 62734 errors 1040, bad file extent, some csum missing Turns out this is just btrfs check noise. There's definitely no corruption. These files still pass journalctl --verify which is checking its own internal checksumming in the journal file. I don't know what's best practice. I think on any kind of flash media, I'd rather not have +C by default, so that the logs compress on the fly, and also rather not have defragment on rotate because that also just increases wear by rewriting everything. Yes the journals are heavily fragmented if they are allowed to COW, but I don't think I really care about legacy files being a little slower on flash. *shrug* Chris Murphy
