[lustre-devel] [RFC] Lustre Upstreaming Project Update

Last year, we attended LSF to talk about upstreaming the Lustre filesystem
[1]. I wanted to share an update (to fsdevel and lustre-devel) about the
work we've achieved and our plans in the coming year.

We outlined a plan [2] for converting our out-of-tree repository into a
clean patch series on the mainline kernel. This process would involve
splitting our existing code base into a set of clean, idiomatic kernel
modules and a lustre_compat/ backward compatibility layer to support
existing users of Lustre on LTS kernels. So far, the initial split has
been mostly completed and we are working on simplifying the Lustre build
system and starting to clean up inline non-CONFIG #ifdefs. I originally
estimated that we would be able to post patches on the mailing list by
November 2026. But I think 2027Q1 is more likely, given the current amount
of outstanding work.

A summary of the major ongoing projects can be seen on our wiki page [2].
The folio transition is ongoing and predicted to land in the coming months,
with some of the initial patches landing sooner. We continue to move away
from Lustre's custom (or out-of-tree) interfaces - such as converting to
rhashtable or adopting the p2pdma framework. Most of the code base has
been converted (or is in the process of being converted) to more standard
kernel style - with recent patches focusing on converting from Doxygen to
kernel-doc for code comments. There are several smaller projects and
tasks that are ongoing.

Although we have primarily focused on the Lustre client - the Lustre client
and server are closely linked and we intend to upstream them both (either
in quick succession or together). Our initial submission of the server code
will only include the in-memory storage backend. Although work continues on
preparing to upstream changes to ext4 to work as a backend, we don't expect
that work will be included in the initial submission of the server code.
This will greatly simplify upstreaming efforts while still enabling developers
to easily test their Lustre code changes.

Regarding testing, I've set up a modest test bot to validate different
build configurations on the latest mainline kernels [3]. While Lustre
already has extensive per-patch testing [4][5], this bot is focused solely
on the needs and requirements of the upstreaming project. Linux supports a
large variety of platforms and configurations that Lustre customers typically
do not use. But we want to validate as many of these configurations as possible
(at least at a basic level) to minimize friction in the future. As we get
closer to upstreaming, we may investigate KernelCI [6] to surface some of these
issues (in addition to our other testing).

Overall, I think we made solid progress. While there is some work that I
wish we could have finished by now, I'm optimistic that we will achieve the
bulk of our goals by this time next year. There will be more discussion
about the state of the upstreaming project at the upcoming Lustre User
Group [7]. This will also give us a chance to discuss issues pertinent to
upstreaming in-person. We will not be attending LSF this year - although
we may attend in the future (as needed) once we have officially submitted
patches for review. Until then, I'm looking forward to another productive
year.

Tim Day

[1] "Getting Lustre Upstream" - https://lwn.net/Articles/1025268/
[2] Wiki - https://wiki.lustre.org/Lustre_Upstreaming_to_Linux_Kernel
[3] Upstream Testing Bot - https://tim-day-387.github.io/upstream-patch-review/#
[4] Jenkins - https://build.whamcloud.com/
[5] Maloo Testing - https://testing.whamcloud.com/
[6] KernelCI - https://kernelci.org/
[7] LUG2026 - https://www.opensfs.org/lug-2026/


_______________________________________________
lustre-devel mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org