[0/9,V3] btrfs: break up extent_io.c a little bit
mbox series

Message ID 20190923140525.14246-1-josef@toxicpanda.com
Headers show
Series
  • btrfs: break up extent_io.c a little bit
Related show

Message

Josef Bacik Sept. 23, 2019, 2:05 p.m. UTC
v1->v2:
- renamed find_delalloc_range to btrfs_find_delalloc_range for now.

-- Original email --

Currently extent_io.c includes all of the extent-io-tree code, the extent buffer
code, the code to do IO on extent buffers and data extents, as well as a bunch
of other random stuff.  The random stuff just needs to be cleaned up, and is
probably too invasive for this point in the development cycle.  Instead I simply
tackled moving the big obvious things out into their own files.  I will follow
up with cleanups for the rest of the stuff, but those can probably wait until
the next cycle as they are going to be slightly more risky.  As usual I didn't
try to change anything, I simply moved code around.  Any time I needed to make
actual changes to functions I made a separate patch for that work, so for
example breaking up the init/exit functions for extent-io-tree.  Everything else
is purely cut and paste into new files.  The diffstat is as follows

 fs/btrfs/Makefile         |    3 +-
 fs/btrfs/ctree.h          |    3 +-
 fs/btrfs/disk-io.h        |    2 +
 fs/btrfs/extent-buffer.c  | 1266 ++++++++
 fs/btrfs/extent-buffer.h  |  152 +
 fs/btrfs/extent-io-tree.c | 1955 ++++++++++++
 fs/btrfs/extent-io-tree.h |  248 ++
 fs/btrfs/extent_io.c      | 7555 +++++++++++++--------------------------------
 fs/btrfs/extent_io.h      |  372 +--
 fs/btrfs/super.c          |   16 +-
 10 files changed, 5843 insertions(+), 5729 deletions(-)

Thanks,

Josef

Comments

David Sterba Sept. 23, 2019, 2:32 p.m. UTC | #1
On Mon, Sep 23, 2019 at 10:05:16AM -0400, Josef Bacik wrote:
> v1->v2:
> - renamed find_delalloc_range to btrfs_find_delalloc_range for now.

The series is V3, what changed V2->V3?
Josef Bacik Sept. 23, 2019, 2:46 p.m. UTC | #2
On Mon, Sep 23, 2019 at 04:32:19PM +0200, David Sterba wrote:
> On Mon, Sep 23, 2019 at 10:05:16AM -0400, Josef Bacik wrote:
> > v1->v2:
> > - renamed find_delalloc_range to btrfs_find_delalloc_range for now.
> 
> The series is V3, what changed V2->V3?

Wtf, I must not have saved.  It should have had

v2->v3:
- Fix build errors with CONFIG_BTRFS_DEBUG turned on.

Thanks,

Josef
David Sterba Sept. 23, 2019, 5:01 p.m. UTC | #3
On Mon, Sep 23, 2019 at 10:05:16AM -0400, Josef Bacik wrote:
> v1->v2:
> - renamed find_delalloc_range to btrfs_find_delalloc_range for now.
> 
> -- Original email --
> 
> Currently extent_io.c includes all of the extent-io-tree code, the extent buffer
> code, the code to do IO on extent buffers and data extents, as well as a bunch
> of other random stuff.  The random stuff just needs to be cleaned up, and is
> probably too invasive for this point in the development cycle.  Instead I simply
> tackled moving the big obvious things out into their own files.  I will follow
> up with cleanups for the rest of the stuff, but those can probably wait until
> the next cycle as they are going to be slightly more risky.  As usual I didn't
> try to change anything, I simply moved code around.  Any time I needed to make
> actual changes to functions I made a separate patch for that work, so for
> example breaking up the init/exit functions for extent-io-tree.  Everything else
> is purely cut and paste into new files.  The diffstat is as follows
> 
>  fs/btrfs/Makefile         |    3 +-
>  fs/btrfs/ctree.h          |    3 +-
>  fs/btrfs/disk-io.h        |    2 +
>  fs/btrfs/extent-buffer.c  | 1266 ++++++++
>  fs/btrfs/extent-buffer.h  |  152 +
>  fs/btrfs/extent-io-tree.c | 1955 ++++++++++++
>  fs/btrfs/extent-io-tree.h |  248 ++
>  fs/btrfs/extent_io.c      | 7555 +++++++++++++--------------------------------
>  fs/btrfs/extent_io.h      |  372 +--
>  fs/btrfs/super.c          |   16 +-
>  10 files changed, 5843 insertions(+), 5729 deletions(-)

I got some strange merge conflicts, it turns out patch 6/9 did not make
it to the mailinglist (nor patchwork where I could pick it eventually).
For that it's useful to have the list of commits too along with the
diffstat, ie. what format-patch generates.
Josef Bacik Sept. 23, 2019, 6:21 p.m. UTC | #4
On Mon, Sep 23, 2019 at 07:01:01PM +0200, David Sterba wrote:
> On Mon, Sep 23, 2019 at 10:05:16AM -0400, Josef Bacik wrote:
> > v1->v2:
> > - renamed find_delalloc_range to btrfs_find_delalloc_range for now.
> > 
> > -- Original email --
> > 
> > Currently extent_io.c includes all of the extent-io-tree code, the extent buffer
> > code, the code to do IO on extent buffers and data extents, as well as a bunch
> > of other random stuff.  The random stuff just needs to be cleaned up, and is
> > probably too invasive for this point in the development cycle.  Instead I simply
> > tackled moving the big obvious things out into their own files.  I will follow
> > up with cleanups for the rest of the stuff, but those can probably wait until
> > the next cycle as they are going to be slightly more risky.  As usual I didn't
> > try to change anything, I simply moved code around.  Any time I needed to make
> > actual changes to functions I made a separate patch for that work, so for
> > example breaking up the init/exit functions for extent-io-tree.  Everything else
> > is purely cut and paste into new files.  The diffstat is as follows
> > 
> >  fs/btrfs/Makefile         |    3 +-
> >  fs/btrfs/ctree.h          |    3 +-
> >  fs/btrfs/disk-io.h        |    2 +
> >  fs/btrfs/extent-buffer.c  | 1266 ++++++++
> >  fs/btrfs/extent-buffer.h  |  152 +
> >  fs/btrfs/extent-io-tree.c | 1955 ++++++++++++
> >  fs/btrfs/extent-io-tree.h |  248 ++
> >  fs/btrfs/extent_io.c      | 7555 +++++++++++++--------------------------------
> >  fs/btrfs/extent_io.h      |  372 +--
> >  fs/btrfs/super.c          |   16 +-
> >  10 files changed, 5843 insertions(+), 5729 deletions(-)
> 
> I got some strange merge conflicts, it turns out patch 6/9 did not make
> it to the mailinglist (nor patchwork where I could pick it eventually).
> For that it's useful to have the list of commits too along with the
> diffstat, ie. what format-patch generates.

Huh weird.  I see you merged up through patch 5, I'll rebase and resend and
maybe this time the ML will take it.

How about I start sending pull requests through github for everything in
addition to sending stuff to the mailinglist, that way it's easier to track the
bigger things?  Thanks,

Josef
David Sterba Sept. 24, 2019, 7:46 a.m. UTC | #5
On Mon, Sep 23, 2019 at 02:21:04PM -0400, Josef Bacik wrote:
> > I got some strange merge conflicts, it turns out patch 6/9 did not make
> > it to the mailinglist (nor patchwork where I could pick it eventually).
> > For that it's useful to have the list of commits too along with the
> > diffstat, ie. what format-patch generates.
> 
> Huh weird.  I see you merged up through patch 5, I'll rebase and resend and
> maybe this time the ML will take it.

Yeah I merged what I had, even some of the 7-9 applied but that could
cause conflicts after your changes.

> How about I start sending pull requests through github for everything in
> addition to sending stuff to the mailinglist, that way it's easier to track the
> bigger things?  Thanks,

You can always send a link to git branch with the patches, not only for
cases like that, but we also want the mailig list copy. I almost always
process the mailinglist to send replies and to check previous
iterations. IOW, git branch is for convenience.
Josef Bacik Sept. 24, 2019, 1:18 p.m. UTC | #6
On Tue, Sep 24, 2019 at 09:46:15AM +0200, David Sterba wrote:
> On Mon, Sep 23, 2019 at 02:21:04PM -0400, Josef Bacik wrote:
> > > I got some strange merge conflicts, it turns out patch 6/9 did not make
> > > it to the mailinglist (nor patchwork where I could pick it eventually).
> > > For that it's useful to have the list of commits too along with the
> > > diffstat, ie. what format-patch generates.
> > 
> > Huh weird.  I see you merged up through patch 5, I'll rebase and resend and
> > maybe this time the ML will take it.
> 
> Yeah I merged what I had, even some of the 7-9 applied but that could
> cause conflicts after your changes.
> 
> > How about I start sending pull requests through github for everything in
> > addition to sending stuff to the mailinglist, that way it's easier to track the
> > bigger things?  Thanks,
> 
> You can always send a link to git branch with the patches, not only for
> cases like that, but we also want the mailig list copy. I almost always
> process the mailinglist to send replies and to check previous
> iterations. IOW, git branch is for convenience.

Yeah I'm not saying replace the mailinglist stuff, but augment it with a github
PR to make sure things don't get lost.  I'll follow up with that shortly.

Josef