| Message ID | 20190923140525.14246-1-josef@toxicpanda.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | btrfs: break up extent_io.c a little bit | expand |
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?
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
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.
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
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.
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