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). -- 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
