On 2018年04月09日 23:05, David Sterba wrote: > On Mon, Apr 09, 2018 at 10:29:34PM +0800, Qu Wenruo wrote: >>>> --- a/cmds-inspect-dump-tree.c >>>> +++ b/cmds-inspect-dump-tree.c >>>> @@ -303,7 +303,9 @@ int cmd_inspect_dump_tree(int argc, char **argv) >>>> int uuid_tree_only = 0; >>>> int roots_only = 0; >>>> int root_backups = 0; >>>> - unsigned open_ctree_flags = OPEN_CTREE_FS_PARTIAL; >>>> + /* Speed up open_ctree() and continue if extent tree is corrupted */ >>>> + unsigned open_ctree_flags = OPEN_CTREE_PARTIAL | >>>> + OPEN_CTREE_NO_BLOCK_GROUPS; >>> >>> We could consider that separatelly, whether to allow dumping a partially >>> created filesystem, ie. OPEN_CTREE_FS_PARTIAL added by a new option. >> >> For dump-tree, there is really no limitation here. >> As long as chunk tree is OK, we should be OK to do "-b" dump. >> >> For "-t" or all tree (default) dump, with chunk tree opened only, we >> could try our best to print any good trees. >> So I don't get the point to read all other trees. > > Yeah, eg. a bad filesystem magic number does not stop dump-tree, so no > change is needed.
Bad magic will still stop dump-tree, super block check is not affected by open ctree flags. The only way to block dump-tree is corrupted chunk tree, which mostly makes the fs garbage. Even root tree is corrupted, we can still specify bytenr manually to salvage what we need. The point here is still the same, for read-only operations where we don't care about the cross-reference, there is no need to care about extent tree at all, and skip block group item search could save us a lot of time. Thanks, Qu > -- 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
