On 07/04/2018 05:40 AM, Marc MERLIN wrote:
On Tue, Jul 03, 2018 at 03:34:45PM -0600, Chris Murphy wrote:
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.
Yeah, I'm fine waiting a few more ays with this down and gather data if
that helps.
Thanks! I will write a special version which skips to check wrong extent
items and print debug log.
And it must run faster to help us locate the stuck problem.
Su
But due to the size, a full btrfs image may be a bit larger than we
want, not counting some confidential data in some filenames.
Marc
--
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
