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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to