[00/25] btrfs: migrate the block group code
mbox series

Message ID 20190620193807.29311-1-josef@toxicpanda.com
Headers show
Series
  • btrfs: migrate the block group code
Related show

Message

Josef Bacik June 20, 2019, 7:37 p.m. UTC
This is the series to migrate the block group code out of extent-tree.c.  This
is a much larger series than the previous two series because things were much
more intertwined than block_rsv's and space_info.  There is one code change
patch in this series, it is

btrfs: make caching_thread use btrfs_find_next_key

This is so I didn't have to copy the simple helper from extent-tree.c into
block-group.c as well.  It's straightforward, but warrants a close look.

The rest is purely moving code around, no code changes at all.  I temporarily
export some functions at different points and then clean it all up at the end.

This patchset brings extent-tree.c down to ~5500 loc.  Thanks,

Josef

Comments

David Sterba Aug. 2, 2019, 1:56 p.m. UTC | #1
On Thu, Jun 20, 2019 at 03:37:42PM -0400, Josef Bacik wrote:
> This is the series to migrate the block group code out of extent-tree.c.  This
> is a much larger series than the previous two series because things were much
> more intertwined than block_rsv's and space_info.  There is one code change
> patch in this series, it is
> 
> btrfs: make caching_thread use btrfs_find_next_key

I've merged 1-10 (ie. up to the patch mentioned above) as it applied
cleanly on current misc-next, the rest produced some conflicts.

Although most of the code is moving from a file to file, I fixed the
coding style as this is the perfect opportunity to update code that does
not change often.

If you're going to send more patchsets like that, please do another pass
after copy&paste of the code. Also note that the SPDX header in new .c
files uses the weird // comments, unlike headers that use /* */ .
Josef Bacik Aug. 2, 2019, 2:07 p.m. UTC | #2
On Fri, Aug 02, 2019 at 03:56:38PM +0200, David Sterba wrote:
> On Thu, Jun 20, 2019 at 03:37:42PM -0400, Josef Bacik wrote:
> > This is the series to migrate the block group code out of extent-tree.c.  This
> > is a much larger series than the previous two series because things were much
> > more intertwined than block_rsv's and space_info.  There is one code change
> > patch in this series, it is
> > 
> > btrfs: make caching_thread use btrfs_find_next_key
> 
> I've merged 1-10 (ie. up to the patch mentioned above) as it applied
> cleanly on current misc-next, the rest produced some conflicts.
> 
> Although most of the code is moving from a file to file, I fixed the
> coding style as this is the perfect opportunity to update code that does
> not change often.
> 
> If you're going to send more patchsets like that, please do another pass
> after copy&paste of the code. Also note that the SPDX header in new .c
> files uses the weird // comments, unlike headers that use /* */ .

I'm working off of next-fixes on git.kernel.org, and it looks like you have all
my patches there.  Is there a different branch that I'm supposed to be working
off of?  Thanks,

Josef
David Sterba Aug. 2, 2019, 6:05 p.m. UTC | #3
On Fri, Aug 02, 2019 at 10:07:17AM -0400, Josef Bacik wrote:
> On Fri, Aug 02, 2019 at 03:56:38PM +0200, David Sterba wrote:
> > On Thu, Jun 20, 2019 at 03:37:42PM -0400, Josef Bacik wrote:
> > > This is the series to migrate the block group code out of extent-tree.c.  This
> > > is a much larger series than the previous two series because things were much
> > > more intertwined than block_rsv's and space_info.  There is one code change
> > > patch in this series, it is
> > > 
> > > btrfs: make caching_thread use btrfs_find_next_key
> > 
> > I've merged 1-10 (ie. up to the patch mentioned above) as it applied
> > cleanly on current misc-next, the rest produced some conflicts.
> > 
> > Although most of the code is moving from a file to file, I fixed the
> > coding style as this is the perfect opportunity to update code that does
> > not change often.
> > 
> > If you're going to send more patchsets like that, please do another pass
> > after copy&paste of the code. Also note that the SPDX header in new .c
> > files uses the weird // comments, unlike headers that use /* */ .
> 
> I'm working off of next-fixes on git.kernel.org, and it looks like you have all
> my patches there.  Is there a different branch that I'm supposed to be working
> off of?  Thanks,

The k.org tree should not be used for development, the branches are for
interaction with other trees like linux-next or sent to Linus.

The for-next is an integration branch, the development should be based
off either misc-next or eg. last rc to avoid conflicts.

Current misc-next contains only first 10 patches from this series, the
rest I'll process next week.
David Sterba Aug. 6, 2019, 4:43 p.m. UTC | #4
On Fri, Aug 02, 2019 at 03:56:38PM +0200, David Sterba wrote:
> On Thu, Jun 20, 2019 at 03:37:42PM -0400, Josef Bacik wrote:
> > This is the series to migrate the block group code out of extent-tree.c.  This
> > is a much larger series than the previous two series because things were much
> > more intertwined than block_rsv's and space_info.  There is one code change
> > patch in this series, it is
> > 
> > btrfs: make caching_thread use btrfs_find_next_key
> 
> I've merged 1-10 (ie. up to the patch mentioned above) as it applied
> cleanly on current misc-next, the rest produced some conflicts.

11-25 is now in testing and will be in misc-next soon.

I merged most of the patches manually, there were several updates (code
and coding style) in the moved code. As I don't want to do that painful
exercise again, patchsets like that must come last before the pull
request branch is frozen. This worked well with the other code moving
patchsets (3 patchsets, 23 patches in total).

This one alone has about the same amount of patches, which appears to
bee too much as the number of conflicts increases as other changes get
merged. So the recommended approach is to do that in smaller batches and
do next once the previous is merged.