On 19.03.2018 12:28, Qu Wenruo wrote:
> Commit Fixes: 8c36786c8198 ("btrfs-progs: print-tree: Print offset as tree objectid for ROOT_ITEM")
> changes how we translate offset of ROOT_ITEM.
>
> However the fact is, even for ROOT_ITEM, we have different meaning of
> offset.
>
> For tree reloc tree, it's indeed subvolume id.
> But for other trees, it's the transid of when it's created.
>
> Fix it.
>
> Reported-by: Nikolay Borisov <nborisov@xxxxxxxx>
> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
> ---
> print-tree.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/print-tree.c b/print-tree.c
> index 45350fea0963..848e296c4e67 100644
> --- a/print-tree.c
> +++ b/print-tree.c
> @@ -834,7 +834,16 @@ void btrfs_print_key(struct btrfs_disk_key *disk_key)
> */
> case BTRFS_ROOT_ITEM_KEY:
> printf(" ");
> - print_objectid(stdout, offset, type);
> + /*
> + * Normally offset of ROOT_ITEM should presents the generation
> + * when this root is created.
> + * However if this is tree reloc tree, offset is the subvolume
> + * id of its source. Here we do extra check on this.
> + */
> + if (objectid == BTRFS_TREE_RELOC_OBJECTID)
> + print_objectid(stdout, offset, type);
Do we even have to do this for the reloc tree. If the offset is just a
numeric id tied to a subvolume then the only possible value different
than a numerci value is FS_TREE (in case we have 5 as the source subvol)
but even this is not very informative. I'd suggest just leaving it as a
numeric value.
> + else
> + printf("%lld", offset);
> printf(")");
> break;
> default:
>
--
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
