On Mon, May 25, 2020 at 4:47 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, May 25, 2020 at 2:39 PM Marc MERLIN <marc@xxxxxxxxxxx> wrote: > > > > On Mon, May 25, 2020 at 02:24:03PM -0600, Chris Murphy wrote: > > > 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). > > > > Correct on all points. > > > > > So I guess the real question is what happened to this file system > > > before the send, that got it into this weird state. > > > > That too, but honestly there are a lot of variables, and it feels like a > > bit of wild goose chase. > > Maybe. The story arc on Btrfs is that check --repair only fixes the > things it knows how to fix. It's gotten better but still has the scary > warning, and lately has a 10 second delay to really make sure the user > meant to use it. And regardless of mode, it's slow and just can't > scale. Neither does "wipe and restore from backup". So the problems of > inconsistency need to be understood to avoid the problem in the first > place. > > > > > > Basically it looked like the issues with the FS are pretty minor (I was > > able to cp -av the entire data without any file error), but that btrfs > > check --repair is unable to make it right, which will likely force me to > > wipe and restore. > > I know chedk is WIP, and that's why I'm providing feedback :) > > What about finding inode 14058737 and deleting it? In all of the > listed subvolumes? And then unmount and check again? Before deleting it, can you check if chattr +C is set? Or what kind of file is this? Because there's an old loophole in older kernels where chattr +C could be set, but if defragmented while mounted with a compression option, it would get compressed. And btrfs check complains about it, but it's not actually a problem. Newer kernels don't do this but I'm not certain about the send error's relationship with this. You could try just making a 'cp --reflink=never' copy of the file. And delete the original (and all of its copies in all subvolumes). Now 'btrfs check'. -- Chris Murphy
