From: David Sterba <dsterba@suse.cz>
To: dsterba@suse.cz, Josef Bacik <josef@toxicpanda.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 00/10] btrfs-progs: mkfs fixes and prep work for extent tree v2
Date: Fri, 3 Sep 2021 15:53:16 +0200 [thread overview]
Message-ID: <20210903135316.GD3379@twin.jikos.cz> (raw)
In-Reply-To: <20210825135839.GK3379@twin.jikos.cz>
On Wed, Aug 25, 2021 at 03:58:39PM +0200, David Sterba wrote:
> On Mon, Aug 23, 2021 at 04:14:45PM -0400, Josef Bacik wrote:
> > In order to reduce the amount of pain the reviewers have to endure I'm going to
> > be sending any prepatory patches separately from the actual feature work.
> >
> > To that end this is the first batch of preparatory patches. These are to make
> > working with mkfs a lot easier for the changes I'm making. These are all fixes
> > or enhancements that can apply currently. The only thing that is extent tree v2
> > specific is the last patch, which adds the incompat flag.
> >
> > I've added the patch for the incompat flag because I will have other preparatory
> > patches that add helpers that essentially do
> >
> > if (!btrfs_fs_incompat(fs_info, EXTENT_TREE_V2))
> > /* Do the old thing. */
> >
> > and then have patches after that add the extent tree v2 magic. I think this
> > will make it easier to break up the work, but if we're not comfortable reserving
> > the bit then I'm fine with dropping that last patch. It will just mean future
> > prep work will have to come along with the feature enablement patches.
>
> Going through the patches I don't think mentioning the extent tree v2
> makes sense in case the patch is an independent cleanup or refactors
> some code to be a bit more generic.
I've rephrased some of the changelogs regarding v2.
> The actual incompat bit could be reserved but it would be better to keep
> it in the future patchset implementing some significant part of the
> extent tree v2.
>
> Even with the "if (EXTENT_TREE_V2)" in place it becomes the
> implementation and given that I haven't read the whole design doc for
> that I'm worried that once I find time for that and would suggest some
> changes the reply would be "no I did it this way, it's implemented,
> would require too many changes".
The design is still flexile enough for the questions I had so we can
proceed.
> Would be good to keep mentioning the v2 tree maybe to the cover letter
> so we know what's the motivation but in the changelogs it's confusing as
> we don't have any base point for that.
So the plan is to merge it as the experimental feature and patches will
arrive, which means referencing v2 extent tree is ok and you can keep
using it.
Patches added to devel.
next prev parent reply other threads:[~2021-09-03 13:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-23 20:14 [PATCH v2 00/10] btrfs-progs: mkfs fixes and prep work for extent tree v2 Josef Bacik
2021-08-23 20:14 ` [PATCH v2 01/10] btrfs-progs: mkfs: use an associative array for init blocks Josef Bacik
2021-08-23 20:14 ` [PATCH v2 02/10] btrfs-progs: mkfs: get rid of MKFS_SUPER_BLOCK Josef Bacik
2021-08-23 20:14 ` [PATCH v2 03/10] btrfs-progs: mkfs: use blocks_nr to determine the super used bytes Josef Bacik
2021-08-23 20:14 ` [PATCH v2 04/10] btrfs-progs: mkfs: set nritems based on root items written Josef Bacik
2021-08-23 20:14 ` [PATCH v2 05/10] btrfs-progs: mkfs: add helper for writing empty tree nodes Josef Bacik
2021-08-23 20:14 ` [PATCH v2 06/10] btrfs-progs: make sure track_dirty and ref_cows is set properly Josef Bacik
2021-08-23 20:14 ` [PATCH v2 07/10] btrfs-progs: mkfs: add the block group item in make_btrfs() Josef Bacik
2021-08-23 20:14 ` [PATCH v2 08/10] btrfs-progs: add add_block_group_free_space helper Josef Bacik
2021-08-23 20:14 ` [PATCH v2 09/10] btrfs-progs: mkfs: generate free space tree at make_btrfs() time Josef Bacik
2021-10-11 1:24 ` Qu Wenruo
2021-08-23 20:14 ` [PATCH v2 10/10] btrfs-progs: add the incompat flag for extent tree v2 Josef Bacik
2021-08-25 13:58 ` [PATCH v2 00/10] btrfs-progs: mkfs fixes and prep work " David Sterba
2021-09-03 13:53 ` David Sterba [this message]
2021-10-11 18:35 ` Goffredo Baroncelli
2021-10-11 18:47 ` David Sterba
2021-10-11 19:39 ` Goffredo Baroncelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210903135316.GD3379@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).