Re: kernel 5.16 sprint planning

[Chandan Babu R <chandan.babu@oracle.com>]

On 22 Sep 2021 at 08:32, Darrick J. Wong wrote:
> Hi everyone,
>
> Now that the LPC fs track is over, I would like to take nominations for
> which patchsets do people think they'd like to submit for 5.16, as well
> as volunteers to review those submissions.
>
> I can think of a few things that /could/ be close to ready:
>
>  - Allison's logged xattrs (submitted for review during 5.15 and Dave
>    started playing around with it)
>
>  - Dave's logging parallelization patches (submitted during 5.14 but
>    pulled back at the last minute because of unrelated log recovery
>    issues uncovered)
>
>  - Chandan's large extent counter series, which requires the btree
>    cursor reworking that I sent last week

IMHO the following are the dependencies w.r.t large extent counter patch
series,
1. Any objections towards the approach taken by the patchset to allow
   upgrading older V5 filesystems.
2. "Btree cursor rework" patchset on which large extent counter patchset will
   be based on. If you think btree cursor rework patchset can be completed
   quickly enough to give me time (which shouldn't be more than a week) to
   rebase the large extent counter patch series and test it, then I think my
   patchset can be considered for merging.

One of the things that I missed was that bulkstat ioctl calls made by libfrog
had to check for the presence of XFS_FSOP_GEOM_FLAGS_NREXT64 before including
the newly defined XFS_BULK_IREQ_BULKSTAT and XFS_BULK_IREQ_BULKSTAT_NREXT64
flags in the bulkstat header. I have fixed it now.

>
>  - A patchset from me to reduce sharply the size of transaction
>    reservations when rmap and reflink are enabled.
>
> Would anyone like to add items to this list, or remove items?
>
> For each of the items /not/ authored by me, I ask the collaborators on
> each: Do you intend to submit this for consideration for 5.16?  And do
> you have any reviewers in mind?
>
> For everyone else: Do you see something you'd like to see land in 5.16?
> Would you be willing to pair off with the author(s) to conduct a review?

I can work on reviewing delayed xattrs and associated patchsets (e.g. Dave's
intent whiteout series).

>
> -------
>
> Carlos asked after the FS track today about what kinds of things need
> working on.  I can think of two things needing attention in xfsprogs:
>
>  - Helping Eric deal with the xfs_perag changes that require mockups.
>    (I might just revisit this, since I already threw a ton of patches at
>    the list.)
>
>  - Protofiles: I occasionally get pings both internally and via PM from
>    people wanting to create smallest-possible prepopulated XFS images
>    from a directory tree.  Exploding minimum-sized images aren't a great
>    idea because the log and AGs will be very small, but:
>
>    Given that we have a bitrotting tool (xfs_estimate) to guesstimate
>    the size of the image, mkfs support for ye olde 4th Ed. Unix
>    protofiles, and I have a script to generate protofiles, should
>    someone clean all that up into a single tool that converts a
>    directory tree into an image?  Preferably one with as large an AG+log
>    as possible?
>
>    Or should we choose to withdraw all that functionality?
>
>    I have a slight greybeard preference for keeping protofiles on the
>    grounds that protofiles have been supported on various Unix mkfs for
>    almost 50 years, and they're actually compatible with the JFS tools
>    and <cough> other things like AIX and HPUX.  But the rest of you can
>    overrule me... ;)
>
> Does anyone have any suggestions beyond that?
>
> --Darrick


-- 
chandan