On Mon, May 25, 2020 at 2:16 PM Marc MERLIN <marc@xxxxxxxxxxx> wrote: > > On Mon, May 25, 2020 at 10:37:58AM -0600, Chris Murphy wrote: > > On Sun, May 24, 2020 at 3:31 PM Marc MERLIN <marc@xxxxxxxxxxx> wrote: > > > > > > My data is fine, it's double backed up and the filesystem is still mountable without issues. > > > But I had an error that broke btrfs send, and after fixing it with repair, I'm stuck with thses 'csum missing' > > > > I'm not following the sequence of events. The send|receive failed? Did > > you try deleting the failed received snapshot? > > btrfs send failed because there was an error on the source filesystem. > Then I found this in the logs > BTRFS error (device dm-0): did not find backref in send_root. inode=14058737, offset=0, disk_byte=2694234112 found extent=2694234112 > > then I ran the btrfs check repair, with and without lowmem. > They fixed some things, but leave me OK I didn't understand that the problem is with only the sending file system, not the receive file system. And also it sounds like the send did not cause the problem, but it's somehow a pre-existing problem that --repair isn't completely fixing up, or maybe is making different (or worse). So I guess the real question is what happened to this file system before the send, that got it into this weird state. > > > Is no-holes enabled on either file system? > > Not intentionally. How do I check? btrfs insp dump-s It's not yet the default and can't be inadvertently enabled so chances are it's the original holes implementation. -- Chris Murphy
