Re: [PATH 5.10 0/4] xfs stable candidate patches for 5.10.y (part 1)

[Amir Goldstein <amir73il@gmail.com>]

On Thu, May 26, 2022 at 8:27 PM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Wed, May 25, 2022 at 02:17:11PM +0300, Amir Goldstein wrote:
> > Hi all!
> >
> > During LSFMM 2022, I have had an opportunity to speak with developers
> > from several different companies that showed interest in collaborating
> > on the effort of improving the state of xfs code in LTS kernels.
> >
> > I would like to kick-off this effort for the 5.10 LTS kernel, in the
> > hope that others will join me in the future to produce a better common
> > baseline for everyone to build on.
> >
> > This is the first of 6 series of stable patch candidates that
> > I collected from xfs releases v5.11..v5.18 [1].
> >
> > My intention is to post the parts for review on the xfs list on
> > a ~weekly basis and forward them to stable only after xfs developers
> > have had the chance to review the selection.
> >
> > I used a gadget that I developed "b4 rn" that produces high level
> > "release notes" with references to the posted patch series and also
> > looks for mentions of fstest names in the discussions on lore.
> > I then used an elimination process to select the stable tree candidate
> > patches. The selection process is documented in the git log of [1].
> >
> > After I had candidates, Luis has helped me to set up a kdevops testing
> > environment on a server that Samsung has contributed to the effort.
> > Luis and I have spent a considerable amount of time to establish the
> > expunge lists that produce stable baseline results for v5.10.y [2].
> > Eventually, we ran the auto group test over 100 times to sanitize the
> > baseline, on the following configurations:
> > reflink_normapbt (default), reflink, reflink_1024, nocrc, nocrc_512.
> >
> > The patches in this part are from circa v5.11 release.
> > They have been through 36 auto group runs with the configs listed above
> > and no regressions from baseline were observed.
>
> Woot!
>
> > At least two of the fixes have regression tests in fstests that were used
> > to verify the fix. I also annotated [3] the fix commits in the tests.
> >
> > I would like to thank Luis for his huge part in this still ongoing effort
> > and I would like to thank Samsung for contributing the hardware resources
> > to drive this effort.
> >
> > Your inputs on the selection in this part and in upcoming parts [1]
> > are most welcome!
>
> /me wonders if you need commit 9a5280b312e2 xfs: reorder iunlink remove
> operation in xfs_ifree ?  Or did that one already get pulled in?
>

Ok. I added it to my branch.
Note that 5.10.y was not getting any xfs fixes for 2 years, so for now I am
working my way up from v5.11 and not expediting any fixes, because if
downstream users waited for 2 years, they can wait a few more weeks.

My list of candidates was extracted at time of 5.18-rc1 and I intentionally
wanted to let the 5.18 patches soak before I consider them.
I will get to the 5.18 release when I am done posting fixes up to 5.17.

> The changes proposed look reasonable to me, and moreso with the testing
> to prove it.  Minor nit: patchsets should be tagged "PATCH", not "PATH".
>

Oy :)

I'll be sure to fix that when I post to stable.

Thanks,
Amir.