Fresh Raid-1 setup, dump-tree shows invalid owner id
After creating raid1:
$./mkfs.btrfs -f -d raid1 -m raid1 /dev/sda6 /dev/sda7
and using
$./btrfs inspect-internal dump-tree /dev/sda6 #./btrfs-debug-tree /dev/sda6
shows possible wrong value for 'owner'?
--
checksum tree key (CSUM_TREE ROOT_ITEM 0)
leaf 29425664 items 0 free space 16283 generation 4 owner 7
fs uuid 94fee00b-00aa-4d69-b947-347f743117f2
chunk uuid 6477561c-cbca-45e4-980d-56727a8dc9d9
data reloc tree key (DATA_RELOC_TREE ROOT_ITEM 0)
leaf 29442048 items 2 free space 16061 generation 4 owner 18446744073709551607 <<< owner id? fs uuid 94fee00b-00aa-4d69-b947-347f743117f2
chunk uuid 6477561c-cbca-45e4-980d-56727a8dc9d9
--
or is that expected output?
Cheers.
Lakshmipathi.G
Raid1 is irrelevant, looks like this happen with simple case too. $./mkfs.btrfs tests/test.img
$./btrfs-debug-tree tests/test.img
possible issue with ./btrfs-debug-tree stdout?
Quoted 26 lines · Lakshmipathi.G
After creating raid1:
$./mkfs.btrfs -f -d raid1 -m raid1/dev/sda6/dev/sda7and using
$./btrfs inspect-internal dump-tree/dev/sda6#./btrfs-debug-tree/dev/sda6shows possible wrong value for 'owner'?
--
checksum tree key (CSUM_TREEROOT_ITEM0)
leaf 29425664 items 0 free space 16283 generation 4 owner 7
fs uuid 94fee00b-00aa-4d69-b947-347f743117f2
chunk uuid 6477561c-cbca-45e4-980d-56727a8dc9d9
data reloc tree key (DATA_RELOC_TREEROOT_ITEM0)
leaf 29442048 items 2 free space 16061 generation 4 owner 18446744073709551607 <<< owner id? fs uuid 94fee00b-00aa-4d69-b947-347f743117f2
chunk uuid 6477561c-cbca-45e4-980d-56727a8dc9d9
--or is that expected output?
Cheers.
Lakshmipathi.G
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 18 lines · Lakshmipathi.G
After creating raid1:
$./mkfs.btrfs -f -d raid1 -m raid1/dev/sda6/dev/sda7and using
$./btrfs inspect-internal dump-tree/dev/sda6#./btrfs-debug-tree/dev/sda6shows possible wrong value for 'owner'?
--
checksum tree key (CSUM_TREEROOT_ITEM0)
leaf 29425664 items 0 free space 16283 generation 4 owner 7
fs uuid 94fee00b-00aa-4d69-b947-347f743117f2
chunk uuid 6477561c-cbca-45e4-980d-56727a8dc9d9
data reloc tree key (DATA_RELOC_TREEROOT_ITEM0)
leaf 29442048 items 2 free space 16061 generation 4 owner 18446744073709551607 <<< owner id? fs uuid 94fee00b-00aa-4d69-b947-347f743117f2
chunk uuid 6477561c-cbca-45e4-980d-56727a8dc9d9
--
Quoted 1 line
or is that expected output?
Yes, the owner is the number of the tree.
DATA_RELOC_TREE is -9, but then unsigned 64 bits.
Quoted 1 line
Quoted 1 line
Quoted 1 line
-9 + 2**64
18446744073709551607L
So the result is a number that's close to the max or 64 bits.
You can find those numbers in the kernel source in
include/uapi/linux/btrfs_tree.h
e.g.:
#define BTRFS_DATA_RELOC_TREE_OBJECTID -9ULL
Signature · 1 line
Hans van Kranenburg
Quoted 8 lines
Yes, the owner is the number of the tree.
DATA_RELOC_TREEis -9, but then unsigned 64 bits.Quoted 1 line
Quoted 1 line
Quoted 1 line
-9 + 2**64
18446744073709551607L
Quoted 9 lines
So the result is a number that's close to the max or 64 bits.
You can find those numbers in the kernel source in
include/uapi/linux/btrfs_tree.he.g.:
#define
BTRFS_DATA_RELOC_TREE_OBJECTID-9ULL
Thanks for the details. This owner number looked different from other owner ids, so wanted to check on the same, now understood.
Cheers.
Lakshmipathi.G
Quoted 13 lines · Lakshmipathi.G
Quoted 13 lines
Yes, the owner is the number of the tree.
DATA_RELOC_TREEis -9, but then unsigned 64 bits.Quoted 1 line
Quoted 1 line
Quoted 1 line
-9 + 2**64
18446744073709551607L
So the result is a number that's close to the max or 64 bits.
You can find those numbers in the kernel source in
include/uapi/linux/btrfs_tree.h
Quoted 7 lines
Quoted 4 lines
e.g.:
#define
BTRFS_DATA_RELOC_TREE_OBJECTID-9ULLThanks for the details. This owner number looked different from other owner ids, so wanted to check on the same, now understood.
Recently, in the commit 6f6b643e44ef7, the known tree ids are printed as the small negative numbers. We can also do that in progs, however we'd need some tricks so we don't duplicate all format strings one with %llu and one with %lld. Something like
format: "%s%llu"
values:
id > LAST_FREE ? "-" : ""
id > LAST_FREE ? 2^64 - id : id
and hidden in helpers etc.
I don't think we should replace all references to tree ids with the symbolic names as they're used in keys so searching for the numeric value in the dump output would miss something or make the regexp more complicated. I won't object against making the tree id output format selectable by option though.