Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks

From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: dsterba@suse.cz, David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks
Date: Thu, 23 Jun 2016 15:17:10 +0200	[thread overview]
Message-ID: <576BE156.90007@mendix.com> (raw)
In-Reply-To: <20160623131352.GC4915@twin.jikos.cz>

On 06/23/2016 03:13 PM, David Sterba wrote:
> On Thu, Jun 23, 2016 at 12:20:38AM +0200, Hans van Kranenburg wrote:
>>> Printing 'usage' is not default as it's quite slow, it uses the search ioctl
>>> and probably not in the best way, or there's some other issue in the
>>> implementation.
>>
>> Interesting.
>>
>> So after reading this, I wrote a little test to test some scenarios:
>>
>> https://github.com/knorrie/python-btrfs/commit/1ca99880dfa0e14b148f3d9e2b6b381b781eb52d
>>
>> It's very clear that the most optimal way of doing this search is to
>> have nr_items=1 and if possible, specify the length in offset.
>
> And that solved it.
>
> [...]
>
>> It seems that searching in the empty space between
>>    (vaddr BLOCK_GROUP_ITEM length+1) and
>>    (vaddr BLOCK_GROUP_ITEM ULLONG_MAX)
>> is really expensive, while there's absolutely nothing to find.
>
> Yeah, the few BLOCK_GROUP_ITEMs are scattered among tons of EXTENT_ITEMs

On the same vaddr objectid, there should only be at most one extent, and 
EXTENT_ITEM_KEY < BLOCK_GROUP_ITEM_KEY, so the space after the block 
group item should always contain exactly 0 items?

Still it takes very long...

-- 
Hans van Kranenburg - System / Network Engineer
Mendix | Driving Digital Innovation | www.mendix.com