On Tue, May 30, 2017 at 05:05:09PM +0300, Ivan Sizov wrote: > 2017-05-26 3:26 GMT+03:00 Liu Bo <bo.li....@oracle.com>: > >Patch 6 adds scrub support to detect the corruption, so users can be > noticed when they do scrub on a regular basis. > >I'm not sure in the real world what may result in this corruption > > I've caught this type of corruption in the wild. The big rsync backup > always ends with a kernel crash due to BUG() statement in > ctime.h:1779. After applying this patchset and running scrub I've got > following messages: > > [sivan@fruestuck ~]$ dmesg | grep "invalid extent inline" > [ 8812.428673] eb 4631634034688(tree block) invalid extent inline ref type 0 > [ 8812.429148] BTRFS error (device sdb1): scrub: extent > 2994741510144(0x2b944810000) has an invalid extent inline ref type, > ignored. > [ 8812.430086] eb 4631634034688(tree block) invalid extent inline ref type 0 > [ 8812.430569] BTRFS error (device sdb1): scrub: extent > 2994741559296(0x2b94481c000) has an invalid extent inline ref type, > ignored. > > How to find the cause of the corruption? Should I try to fix it, or it > is not dangerous for the filesystem? If I should, how to do that?
Did it also print a btree's leaf's content? If yes, it could show us which inline ref has the issue. It's not easy to tell if it's dangerous because I have no idea what type of extent "2994741559296(0x2b94481c000)" refers to. The command 'btrfs check' in the latest btrfs-progs can fix my test case, which is the simplest one (only touched the inline ref and everything else remained the same). Given that at least two users reported about this, I start thinking about there's something wrong inside our btrfs code. -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
