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?
After I went through the output of leaf's content, most parts of the leaf is sane except the two corrupted items, it's still not clear to me what caused the corruption, there could be some corner cases that I'm not aware of. If fsck doesn't work for you, then a recovery from backup may be the best option. Thanks, -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
