kernel 5.16 sprint planning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

 - 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?

-------

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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux