Re: 5.5 kernel and btrfs-progs v5.6 create and cannot fix 'root 204162 inode 14058737 errors 1000, some csum missing'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


> > > > 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.
>
> The filesystem was definitely created a while ago (2-3 years?)
>
> I have been recently been playing with bees, but I'm reasonably sure I didn't run in on that filesystem
> it lists support for "HOLE extents and btrfs no-holes feature"

It's default except for LZO.


-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux