Message ID | 20181228083806.3204-1-wqu@suse.com (mailing list archive) |
---|---|
Headers | show |
Series | btrfs-progs: Support for BG_TREE feature | expand |
Sorry to bother you again... On 12/28/18 9:38 AM, Qu Wenruo wrote: > This patchset can be fetched from github: > https://github.com/adam900710/btrfs-progs/tree/bg_tree > The basis commit is: > > commit 7d16a2b460182ee98c649533a6975b6e419c3d71 > Author: Qu Wenruo <wqu@suse.com> > Date: Thu Dec 27 13:49:18 2018 +0800 > > btrfs-progs: Create uuid tree with proper contents > > Which is further based on devel branch. > > This patchset provides the needed user space infrastructure for BG_TREE > feature. > > Since it's an new exclusive feature, unlike SKINNY_METADATA, btrfs-progs > is needed to convert existing fs (unmounted) to new format. > > Although I have prepared the functionality, convert_to_bg_tree(), and > already uses it in mkfs, I haven't decided if I should put it under > btrfstune, as btrfstune isn't such offline convert tool. Ok, so, the convert_to_bg_tree still needs wiring up somewhere before it's possible to convert an existing fs? I want to test with a (iSCSI level clone of a) rather large-ish filesystem, so I was searching for how to convert that in place. Do you have an idea for a (quick hack?) way to make this happen? Doing the offline conversion itself is also already an interesting thing, seeing how it behaves with some tens of thousands of block groups... (As the intended audience for it will mostly be people having large filesystems already.) > If anyone has better idea on the new convert tool interface, I'm all > ears. > > For the performance improvement, please check the kernel patchset cover > letter or the last patch. > (SPOILER ALERT: It's super fast) > > Qu Wenruo (6): > btrfs-progs: Refactor excluded extent functions to use fs_info > btrfs-progs: Refactor btrfs_read_block_groups() > btrfs-progs: Enable read-write ability for 'bg_tree' feature > btrfs-progs: mkfs: Introduce -O bg-tree > btrfs-progs: dump-tree/dump-super: Introduce support for bg tree > btrfs-progs: check: Introduce support for bg-tree feature > > check/main.c | 7 +- > check/mode-lowmem.c | 9 +- > cmds-inspect-dump-super.c | 3 +- > cmds-inspect-dump-tree.c | 5 + > ctree.h | 17 +- > disk-io.c | 29 +++- > extent-tree.c | 326 +++++++++++++++++++++++++++----------- > fsfeatures.c | 6 + > mkfs/common.c | 7 +- > mkfs/common.h | 1 + > mkfs/main.c | 57 +++++++ > print-tree.c | 3 + > transaction.c | 1 + > 13 files changed, 365 insertions(+), 106 deletions(-) >
On 2019/2/26 上午12:36, Hans van Kranenburg wrote: > Sorry to bother you again... > > On 12/28/18 9:38 AM, Qu Wenruo wrote: >> This patchset can be fetched from github: >> https://github.com/adam900710/btrfs-progs/tree/bg_tree >> The basis commit is: >> >> commit 7d16a2b460182ee98c649533a6975b6e419c3d71 >> Author: Qu Wenruo <wqu@suse.com> >> Date: Thu Dec 27 13:49:18 2018 +0800 >> >> btrfs-progs: Create uuid tree with proper contents >> >> Which is further based on devel branch. >> >> This patchset provides the needed user space infrastructure for BG_TREE >> feature. >> >> Since it's an new exclusive feature, unlike SKINNY_METADATA, btrfs-progs >> is needed to convert existing fs (unmounted) to new format. >> >> Although I have prepared the functionality, convert_to_bg_tree(), and >> already uses it in mkfs, I haven't decided if I should put it under >> btrfstune, as btrfstune isn't such offline convert tool. > > Ok, so, the convert_to_bg_tree still needs wiring up somewhere before > it's possible to convert an existing fs? Sorry, I haven't investigate more time for this convert. It's more or less expected to be something use it or not so far. > > I want to test with a (iSCSI level clone of a) rather large-ish > filesystem, so I was searching for how to convert that in place. > > Do you have an idea for a (quick hack?) way to make this happen? Btrfs-progs needs extra patch for it, but I haven't implemented it yet. It shouldn't be super complex, but I'm not confident enough yet. If nothing goes wrong, I'll update the btrfs-progs patchset this week with (maybe PoC) offline convert. Thanks, Qu > > Doing the offline conversion itself is also already an interesting > thing, seeing how it behaves with some tens of thousands of block > groups... (As the intended audience for it will mostly be people having > large filesystems already.) > >> If anyone has better idea on the new convert tool interface, I'm all >> ears. >> >> For the performance improvement, please check the kernel patchset cover >> letter or the last patch. >> (SPOILER ALERT: It's super fast) >> >> Qu Wenruo (6): >> btrfs-progs: Refactor excluded extent functions to use fs_info >> btrfs-progs: Refactor btrfs_read_block_groups() >> btrfs-progs: Enable read-write ability for 'bg_tree' feature >> btrfs-progs: mkfs: Introduce -O bg-tree >> btrfs-progs: dump-tree/dump-super: Introduce support for bg tree >> btrfs-progs: check: Introduce support for bg-tree feature >> >> check/main.c | 7 +- >> check/mode-lowmem.c | 9 +- >> cmds-inspect-dump-super.c | 3 +- >> cmds-inspect-dump-tree.c | 5 + >> ctree.h | 17 +- >> disk-io.c | 29 +++- >> extent-tree.c | 326 +++++++++++++++++++++++++++----------- >> fsfeatures.c | 6 + >> mkfs/common.c | 7 +- >> mkfs/common.h | 1 + >> mkfs/main.c | 57 +++++++ >> print-tree.c | 3 + >> transaction.c | 1 + >> 13 files changed, 365 insertions(+), 106 deletions(-) >> >