Re: [PATCH] btrfs: print-tree: print header owner as signed

Qu Wenruo <[email protected]>
Newsgroups org.kernel.vger.linux-btrfs
Message-ID <[email protected]>

在 2026/6/24 13:56, Boris Burkov 写道:
> On Tue, Jun 23, 2026 at 08:25:40AM +0930, Qu Wenruo wrote:
>> When dumpping a tree block, btrfs_header::owner is printed as
>> unsigned, which can result in numbers that are hard to read, e.g:
>>
>>   BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607
>>
>> For the above output, 18446744073709551607 is (s64)-9, the root id of data
>> reloc tree.
>>
>> Despite those pre-defined root ids that are already negative, existing
>> subvolume trees will not have any negative values, as subvolume trees can
>> only utilize the lower 48 bits, so there will be no output change for
>> existing subvolumes, thus no extra confusion.
>>
> 
> What do you think about a macro or function wrapping a switch statement
> that also prints the string name of known trees?

That is possible, but I'm not sure if we need to go this complex for 
kernel modules.

A signed s64 output would be enough for most developers/advanced users 
to debug.
For end users, I do not know if things like 2 or EXTENT_TREE make any 
difference.

> What about some identifying
> info like a volume path for subvol trees? That one might be a stretch.

That's is too dangerous, it will need extra tree search and backref lookup.
Meanwhile for a tree dump inside a kernel, it's already an emergency, 
normally we do not have the extra headroom for such complex workload 
just to make the subvolume id a little easier to read.

Thanks,
Qu

> 
> Anyway, this is already a definite improvement, thanks.
> Reviewed-by: Boris Burkov <[email protected]>
> 
>> Signed-off-by: Qu Wenruo <[email protected]>
>> ---
>>   fs/btrfs/print-tree.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
>> index 87e60a2d4bd8..53e726119ca7 100644
>> --- a/fs/btrfs/print-tree.c
>> +++ b/fs/btrfs/print-tree.c
>> @@ -449,9 +449,9 @@ void btrfs_print_leaf(const struct extent_buffer *l)
>>   	nr = btrfs_header_nritems(l);
>>   
>>   	btrfs_info(fs_info,
>> -		   "leaf %llu gen %llu total ptrs %d free space %d owner %llu",
>> +		   "leaf %llu gen %llu total ptrs %d free space %d owner %lld",
>>   		   btrfs_header_bytenr(l), btrfs_header_generation(l), nr,
>> -		   btrfs_leaf_free_space(l), btrfs_header_owner(l));
>> +		   btrfs_leaf_free_space(l), (s64)btrfs_header_owner(l));
>>   	print_eb_refs_lock(l);
>>   	for (i = 0 ; i < nr ; i++) {
>>   		char key_buf[KEY_TYPE_BUF_SIZE];
>> @@ -600,10 +600,10 @@ void btrfs_print_tree(const struct extent_buffer *c, bool follow)
>>   		return;
>>   	}
>>   	btrfs_info(fs_info,
>> -		   "node %llu level %d gen %llu total ptrs %d free spc %u owner %llu",
>> +		   "node %llu level %d gen %llu total ptrs %d free spc %u owner %lld",
>>   		   btrfs_header_bytenr(c), level, btrfs_header_generation(c),
>>   		   nr, (u32)BTRFS_NODEPTRS_PER_BLOCK(fs_info) - nr,
>> -		   btrfs_header_owner(c));
>> +		   (s64)btrfs_header_owner(c));
>>   	print_eb_refs_lock(c);
>>   	for (i = 0; i < nr; i++) {
>>   		btrfs_node_key_to_cpu(c, &key, i);
>> -- 
>> 2.54.0
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.