On Sat, 2019-08-31 at 17:04 -0600, Chris Murphy wrote: > On Sat, Aug 31, 2019 at 2:26 PM Rann Bar-On <r...@math.duke.edu> > wrote: > > I just downgraded to kernel 4.19, and the supposed corruption > > vanished. > > This may be related to > > > > https://www.spinics.net/lists/linux-btrfs/msg91046.html > > > > If I can provide information that would help fix this issue, I'd be > > glad to, but I cannot upgrade back to kernel 5.2, as I can't risk > > this > > system. > > 5.2 has more strict checks for corruption, exposing the rare case > where metadata in a leaf is corrupt but the checksum was properly > computed. > > > > Btrfs v3.17 > > This is old. I suggest finding a newer version of btrfs-progs, > ideally > latest stable version is 5.2.1. Definitely don't use --repair with > this version. It's safe to use check --readonly (which is the > default) > with this version but probably not that helpful to devs. >
Not really sure why that said 3.17: $ btrfs --version btrfs-progs v5.2.1 Anyway, running btrfs --repair on the file system didn't do anything to fix the above errors. I removed at least one of the corrupt files (the only one that was mode 0) using kernel 4.19. Happy to help further if I can. What would you suggest as far as fixing this or reporting it usefully? If you believe 5.2 isn't causing the corruption, but rather, just exposing it, I'm more than happy to experiment with it. Rann > >
