Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

From: Josef Bacik <jbacik@fb.com>
To: <dsterba@suse.cz>, Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Christian Rohmann <crohmann@netcologne.de>,
	Qu Wenruo <quwenruo@cn.fujitsu.com>,
	John Ettedgui <john.ettedgui@gmail.com>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>,
	btrfs <linux-btrfs@vger.kernel.org>, Chris Mason <clm@fb.com>
Subject: Re: mount btrfs takes 30 minutes, btrfs check runs out of memory
Date: Mon, 25 Jul 2016 09:38:05 -0400	[thread overview]
Message-ID: <0291c034-0514-8788-1bf8-3c6a3b86954c@fb.com> (raw)
In-Reply-To: <20160725130117.GB30795@suse.cz>

On 07/25/2016 09:01 AM, David Sterba wrote:
> On Mon, Jul 18, 2016 at 09:42:50AM -0400, Josef Bacik wrote:
>>>
>>> This makes search for BLOCK_GROUP_ITEM very very very slow if extent tree is
>>> really big.
>>>
>>> On the handle, we search CHUNK_ITEM very very fast, because CHUNK_ITEM are in
>>> their own tree.
>>> (CHUNK_ITEM and BLOCK_GROUP_ITEM are 1:1 mapped)
>>>
>>> So to completely fix it, btrfs needs on-disk format change to put
>>> BLOCK_GROUP_ITEM into their own tree.
>>>
>>> IMHO there maybe be some objection from other devs though.
>>>
>>> Anyway, I add the three maintainers to Cc, and hopes we can get a better idea to
>>> fix it.
>>
>> Yeah I'm going to fix this when I do the per-block group extent tree thing.  Thanks,
>
> Will it be capable of "per- subvolume set" extent trees? IOW, a set of
> subvolumes will could share extents only among the members of the same
> group. The usecase is to start an isolate subvolume and allow snapshots
> (and obviously forbid reflinks outside of the group).
>

I suppose.   The problem is the btrfs_header doesn't have much room for verbose 
descriptions of which root owns it.  We have objectid since it was always 
unique, but in the case of per bg extents we can't use that anymore, so we have 
to abuse flags to say this is an extent root block, and then we know that 
btrfs_header_owner(eb) is really the offset of the root and not the objectid. 
Doing something like having it per subvolume would mean having another flag that 
says this block belongs to a subvolume root, and then have the 
btrfs_header_owner(eb) set to the new offset.

The point I'm making is we can do whatever we want here, but it'll be a little 
strange since we have to use flag bits to indicate what type of root the owner 
points to, so any future modifications will also be format changes.  At least 
once I get this work done we'll be able to more easily add new variations on the 
per-whatever setup.  Thanks,

Josef