On Tue, Jul 3, 2018 at 2:34 AM, Su Yue <suy.fnst@xxxxxxxxxxxxxx> wrote: > Yes, extent tree is the hardest part for lowmem mode. I'm quite > confident the tool can deal well with file trees(which records metadata > about file and directory name, relationships). > As for extent tree, I have few confidence due to its complexity. I have to ask again if there's some metadata integrity mask opion Marc should use to try to catch the corruption cause in the first place? His use case really can't afford either mode of btrfs check. And also check is only backward looking, it doesn't show what was happening at the time. And for big file systems, check rapidly doesn't scale at all anyway. And now he's modifying his layout to avoid the problem from happening again which makes it less likely to catch the cause, and get it fixed. I think if he's willing to build a kernel with integrity checker enabled, it should be considered but only if it's likely to reveal why the problem is happening, even if it can't repair the problem once it's happened. He's already in that situation so masked integrity checking is no worse, at least it gives a chance to improve Btrfs rather than it being a mystery how it got corrupt. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
