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? -- 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
