On Wed, Jan 15, 2020 at 6:29 AM Qu Wenruo <wqu@xxxxxxxx> wrote: > > Relocation is one of the most complex part of btrfs, while it's also the > foundation stone for online resizing, profile converting. > > For such a complex facility, we should at least have some introduction > to it. > > This patch will add an basic introduction at pretty a high level, > explaining: > - What relocation does > - How relocation is done > Only mentioning how data reloc tree and reloc tree are involved in the > operation. > No details like the backref cache, or the data reloc tree contents. > - Which function to refer. > > More detailed comments will be added for reloc tree creation, data reloc > tree creation and backref cache. > > For now the introduction should save reader some time before digging > into the rabbit hole. > > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> > --- > fs/btrfs/relocation.c | 44 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 44 insertions(+) > > diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c > index d897a8e5e430..cd3a15f1716d 100644 > --- a/fs/btrfs/relocation.c > +++ b/fs/btrfs/relocation.c > @@ -23,6 +23,50 @@ > #include "delalloc-space.h" > #include "block-group.h" > > +/* > + * Introduction for btrfs relocation. > + * > + * [What does relocation do] For readability, a blank line here would help. > + * The objective of relocation is to relocate all or some extents of one block > + * group to other block groups. Some? We always relocate all extents of a block group (except if errors happen of course). > + * This is utilized by resize (shrink only), profile converting, or just > + * balance routine to free some block groups. > + * > + * In short, relocation wants to do: > + * Before | After > + * ------------------------------------------------------------------ > + * BG A: 10 data extents | BG A: deleted > + * BG B: 2 data extents | BG B: 10 data extents (2 old + 8 relocated) > + * BG C: 1 extents | BG C: 3 data extents (1 old + 2 relocated) > + * > + * [How does relocation work] > + * 1. Mark the target bg RO > + * So that new extents won't be allocated from the target bg. > + * > + * 2.1 Record each extent in the target bg > + * To build a proper map of extents to be relocated. > + * > + * 2.2 Build data reloc tree and reloc trees > + * Data reloc tree will contain an inode, recording all newly relocated > + * data extents. > + * There will be only one data reloc tree for one data block group. > + * > + * Reloc tree will be a special snapshot of its source tree, containing > + * relocated tree blocks. > + * Each tree referring to a tree block in target bg will get its reloc > + * tree built. > + * > + * 2.3 Swap source tree with its corresponding reloc tree > + * So that each involved tree only refers to new extents after swap. > + * > + * 3. Cleanup reloc trees and data reloc tree. > + * As old extents in the target bg is still referred by reloc trees, > + * we need to clean them up before really freeing the target bg. > + * > + * The main complexity is in step 2.2 and 2.3. step -> steps Thanks. > + * > + * The core entrance for relocation is relocate_block_group() function. > + */ > /* > * backref_node, mapping_node and tree_block start with this > */ > -- > 2.24.1 > -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
