On Tue, Jan 15, 2019 at 5:41 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > The relevant error messages are: > > unable to find ref byte > errno=-2 No such entry > > Somehow a reference byte has been corrupted and inserted into multiple > locations in the tree and it's not repairable: i.e. neither a correct > value can be inferred from other available information, nor do the > tools have a good way to just trim out the item that contains bad key > pointers - part of the problem with just cutting out the bad parts is > it's not clear the problem is made even worse or how far the > corruption extends. > > What's further troubling though is the idea that this corruption might > have propagated to a separate volume via snapshot send receive. Either > of the file systems might still be useful for a developer, it seems to > me important to have some kind of check to make sure it's not possible > for corruption to propagate in this manner. > > In the meantime, I think it's a good idea to do a memory test. There's > some information in the archives about how to do this in a more > reliable way than just memtest86 type tests, but if you can run even a > memtest86 over a weekend it might confirm there's a memory problem. > Unfortunately a pass doesn't necessarily mean there aren't rare > transient problems. Also, this could be related... [ 4368.361487] CPU: 0 PID: 23915 Comm: kworker/u16:11 Tainted: P W O 4.20.1-gentoo #1 Do you know why it's tainted? Looks like an out of tree proprietary module. And also there has been a previous kernel warning but that part of the dmesg isn't included. It's not possible to absolutely exclude an out of tree kernel from being a source of memory corruption, but it makes it a possible suspect and therefore it makes tracking down the source of the problem harder. -- Chris Murphy
