xfsprogs: 5.19 libxfs kernel sync

xfsprogs: 5.19 libxfs kernel sync

[Dave Chinner]

Hi folks,

Now that the 5.19 kernel code is largely stablised for the first
merge, I've been starting to get together the libxfs sync tree for
xfsprogs with all those changes in it. I have built a branch
that can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsprogs-dev.git libxfs-5.19-sync

that contains my work in progress so far. It's build on top of the
current xfsprogs for-next branch. I've ported across everything up
to the start of the LARP series so far, so I have done the porting
of the large extent count work and all the other bits and pieces for
log changes and so on.

For the large extent count work, I have not added any of the
specific new xfsprogs functionality like mkfs, etc. Patches 14-18
of Chandan's V7 patch series here:

https://lore.kernel.org/linux-xfs/20220321052027.407099-1-chandan.babu@oracle.com/

still need to be ported on top of this for the functionality to be
fully supported in xfsprogs.

Chandan, can you port those changes over to this libxfs sync branch
and check that I haven't missed anything in the conversion? I did
pick up one of your patches from that series - "Introduce per-inode
64-bit extent counters" - because of all the xfs_db bits in it for
the change in on-disk format, but otherwise I've largely just worked
through fixing all the compiler errors and converting the xfsprogs
code over to the new functions and types.

If you port the ramin patches over to thsi branch and test them,
I'll include them into the branch. I'll be checking for stability
and regressions on this brnach for the next couple of days, and if
everythign looks OK I'll send Eric a pull request for it....

Once I've done that, I'll work through the same process with the
LARP patches. I'll probably lean heavily on Allison's recent
xfsprogs updates for that (no point doing the same work twice!), but
right now I'm hoping to have the full 5.19 libxfs syncup done with
both large extent counts and LARP fully functional in that branch
before the end of the 5.19 merge window....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: xfsprogs: 5.19 libxfs kernel sync

[Chandan Babu R]

On Tue, May 24, 2022 at 05:05:43 PM +1000, Dave Chinner wrote:
> Hi folks,
>
> Now that the 5.19 kernel code is largely stablised for the first
> merge, I've been starting to get together the libxfs sync tree for
> xfsprogs with all those changes in it. I have built a branch
> that can be found here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsprogs-dev.git libxfs-5.19-sync
>
> that contains my work in progress so far. It's build on top of the
> current xfsprogs for-next branch. I've ported across everything up
> to the start of the LARP series so far, so I have done the porting
> of the large extent count work and all the other bits and pieces for
> log changes and so on.
>
> For the large extent count work, I have not added any of the
> specific new xfsprogs functionality like mkfs, etc. Patches 14-18
> of Chandan's V7 patch series here:
>
> https://lore.kernel.org/linux-xfs/20220321052027.407099-1-chandan.babu@oracle.com/
>
> still need to be ported on top of this for the functionality to be
> fully supported in xfsprogs.
>
> Chandan, can you port those changes over to this libxfs sync branch
> and check that I haven't missed anything in the conversion? I did
> pick up one of your patches from that series - "Introduce per-inode
> 64-bit extent counters" - because of all the xfs_db bits in it for
> the change in on-disk format, but otherwise I've largely just worked
> through fixing all the compiler errors and converting the xfsprogs
> code over to the new functions and types.
>
> If you port the ramin patches over to thsi branch and test them,
> I'll include them into the branch. I'll be checking for stability
> and regressions on this brnach for the next couple of days, and if
> everythign looks OK I'll send Eric a pull request for it....

Apart from a single nit, The "large extent counter" patches already included
in libxfs sync branch look good.

My original patch "xfs: Introduce xfs_dfork_nextents() helper" had an
invocation of "xfs_dfork_data_extents(dip);" in process_dev_inode() instead of
"xfs_dfork_nextents(dip, XFS_DATA_FORK);".

I will try to port the remaining patches by today and will run xfstests
overnight. I will post the patches tomorrow if the test execution doesn't
reveal any bugs.

>
> Once I've done that, I'll work through the same process with the
> LARP patches. I'll probably lean heavily on Allison's recent
> xfsprogs updates for that (no point doing the same work twice!), but
> right now I'm hoping to have the full 5.19 libxfs syncup done with
> both large extent counts and LARP fully functional in that branch
> before the end of the 5.19 merge window....

-- 
chandan

Re: xfsprogs: 5.19 libxfs kernel sync

[Dave Chinner]

On Tue, May 24, 2022 at 06:01:15PM +0530, Chandan Babu R wrote:
> On Tue, May 24, 2022 at 05:05:43 PM +1000, Dave Chinner wrote:
> > Hi folks,
> >
> > Now that the 5.19 kernel code is largely stablised for the first
> > merge, I've been starting to get together the libxfs sync tree for
> > xfsprogs with all those changes in it. I have built a branch
> > that can be found here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsprogs-dev.git libxfs-5.19-sync
> >
> > that contains my work in progress so far. It's build on top of the
> > current xfsprogs for-next branch. I've ported across everything up
> > to the start of the LARP series so far, so I have done the porting
> > of the large extent count work and all the other bits and pieces for
> > log changes and so on.
> >
> > For the large extent count work, I have not added any of the
> > specific new xfsprogs functionality like mkfs, etc. Patches 14-18
> > of Chandan's V7 patch series here:
> >
> > https://lore.kernel.org/linux-xfs/20220321052027.407099-1-chandan.babu@oracle.com/
> >
> > still need to be ported on top of this for the functionality to be
> > fully supported in xfsprogs.
> >
> > Chandan, can you port those changes over to this libxfs sync branch
> > and check that I haven't missed anything in the conversion? I did
> > pick up one of your patches from that series - "Introduce per-inode
> > 64-bit extent counters" - because of all the xfs_db bits in it for
> > the change in on-disk format, but otherwise I've largely just worked
> > through fixing all the compiler errors and converting the xfsprogs
> > code over to the new functions and types.
> >
> > If you port the ramin patches over to thsi branch and test them,
> > I'll include them into the branch. I'll be checking for stability
> > and regressions on this brnach for the next couple of days, and if
> > everythign looks OK I'll send Eric a pull request for it....
> 
> Apart from a single nit, The "large extent counter" patches already included
> in libxfs sync branch look good.
> 
> My original patch "xfs: Introduce xfs_dfork_nextents() helper" had an
> invocation of "xfs_dfork_data_extents(dip);" in process_dev_inode() instead of
> "xfs_dfork_nextents(dip, XFS_DATA_FORK);".

Ok, thatnks for finding that - I'll update the branch I have with
that fix, it shouldn't affect anything else you do on top of it...

> I will try to port the remaining patches by today and will run xfstests
> overnight. I will post the patches tomorrow if the test execution doesn't
> reveal any bugs.

Thanks!

-Dave.
-- 
Dave Chinner
david@fromorbit.com