On Thu, May 26, 2022 at 8:27 PM Darrick J. Wong <djwong@xxxxxxxxxx> 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.
