Lustre Upstreaming to Linux Kernel

The Lustre upstreaming effort is currently being managed as part of the master Lustre development branch, and submitted patches should follow the normal Lustre patch development process, which includes fixing issues reported by checkpatch.pl, so that the code follows the upstream kernel style guidelines. Once all issues in the Lustre code that are known to be blocking upstream submission have been addressed, then the filesystem will be resubmitted to the upstream kernel.

Upstream Filesystem Requirements

The Linux kernel has documented requirements for accepting new filesystems. The following section discussed those requirements.

Do You Need a New In-Kernel Filesystem?

"Before proposing a new in-kernel filesystem, consider whether one of the alternatives might be more appropriate."

Question	Answer
Does an existing in-kernel filesystem cover the same use case?	Lustre targets high performance scale-out network file storage use-cases. The closest analogs in the kernel are pNFS and Ceph. Lustre has a more mature implementation and is generally higher performance than either pNFS or Ceph. Lustre has a fully open-source server, unlike most pNFS implementations where they are only using the Linux client and keeping the server proprietary.
Can we use FUSE?	One of Lustre's highest priorities is performance. FUSE imposes an unacceptable performance tradeoff.

Technical Requirements

Requirement	Upstream guidance	Lustre status
Use modern VFS interfaces	"Do not use interfaces listed in Documentation/process/deprecated.rst."
	"Use folios rather than raw page operations for page cache management."	Lustre is well underway in converting both the client and the server IO paths to folios.
	"Network filesystems should consider using the netfs library Documentation/filesystems/netfs_library.rst, or be prepared to explain why it is not a good fit."	Lustre stripes files over several storage servers. It needs to maintain cache coherence whenever any server revokes a lock for a file range. This requires special callbacks that netfs doesn't support.
Provide userspace utilities	"A mkfs tool is expected ..."	Lustre maintains a mkfs.lustre tool.
	"A fsck tool is strongly recommended ..."	Lustre uses existing local-disk filesystems (modified ext4 -> ldiskfs) for the individual storage targets, and e2fsck is used to repair local filesystem inconsistencies/corruption. Lustre has a dedicated online repair tool, LFSCK, that can detect and repair inconsistencies between the individual target filesystems.
Be testable	"The filesystem must be testable in a meaningful way." "The fstests framework (also known as xfstests) is the standard testing infrastructure for Linux filesystems and its use is highly recommended." "At a minimum, there must be a credible and documented way to test the filesystem and detect regressions. When submitting, include a summary of test results indicating which tests pass, fail, or are not applicable."	Lustre has a large body of existing tests that are run continuously on all patches before integration. Lustre is testable via fstests. We intend to submit fstests support when Lustre is being submitted upstream.
Provide documentation	"A documentation file under Documentation/filesystems/ describing the filesystem, its on-disk format, mount options, and any notable design decisions is recommended."	Lustre has a lot of existing documentation included in the sources for command-line tools and developers that we will submit alongside the filesystem as appropriate. Lustre also has extensive online documentation for usage and administration.

Community and Maintainership Expectations

Requirement	Upstream guidance	Lustre status
Identified maintainers		In no particular order - James Simmons, Timothy Day, Andreas Dilger, Oleg Drokin
Demonstrated commitment	"A track record of maintaining kernel code -- for example, in other subsystems -- significantly strengthens the case for a new filesystem."	Andreas Dilger is one of the long-time contributors to ext2/ext3/ext4/e2fsprogs. Many of the other Lustre developers contributed substantial features to ext4/e2fsprogs.
Sustained backing	"Major filesystems in Linux have organizational or corporate support behind their development."	A non-exhaustive list of domains of contributing organizations in the past 3 years: whamcloud.com, ddn.com, hpe.com, aeoncomputing.com, amazon.com, thelustrecollective.com, infradead.org, cea.fr, nvidia.com, oracle.com, suse.de, lanl.gov, google.com, llnl.gov, linaro.org, openchip.com, microsoft.com, tintri.com, gluesys.com, stanford.edu, cray.com, ornl.gov, jlab.org, intel.com, iastate.edu, eviden.com, codewreck.org, canonical.com, atos.net
Responsiveness	"The maintainer is expected to respond to bug reports, address review feedback, and adapt the filesystem to VFS infrastructure changes such as folio conversions, iomap migration, and mount API updates."	There is a longstanding Lustre issue tracking system that is open to the public (need free account to post issues) as well as Mailing_Lists_and_IRC for users, lustre-devel list for developers, and Slack channel.
User base	"Clearly describe who the users of this filesystem are and the scale of the user base."	Lustre users are widespread across universities and research organizations around the world (e.g. Stanford, UFlorida, ORNL, LLNL, LANL, NCSA, Cambridge, HLRS, CINECA, SFU, NASA), weather forecasting (NOAA, NCAR, DKRZ, ECMWF, BoM, UKMET), energy (CEA, BP, Total), medicine/genomics (Sanger, BGI, Cornell), LLM (NVIDIA, xAI, Anthropic, Softbank), and many other organizations that need high performance and high capacity storage. About 70% of the Top-500 supercomputers for the past 15+ years use Lustre, which implies at least many thousands of large systems use it, and at least hundreds of thousands of direct users. Lustre is freely available through multiple channels, so there is no way to tell the total number of users. There are also multiple vendors selling Lustre-based storage hardware and support offerings directly or indirectly: HPE, AWS, DDN, Google, Azure, Oracle, Aeon, TLC
Building your track record	"A practical way to demonstrate many of the qualities above is to maintain the filesystem out-of-tree for a period before requesting a merge."	Lustre has been in active development out-of-tree for over 25 years and has dozens of full-time developers and many more contributors.

Pending Work

Significant work has gone into improving the Lustre codebase since the Lustre client was removed from staging. Below are listed some of the major areas of ongoing work. This list is not comprehensive. The first ticket LU-12511 links to a lot of work that has been completed historically. This table will be updated periodically as new requirements emerge and as work becomes completed.

Task	Status	Notes	Jira	Patch(es)
Prepare Lustre for Adoption in the Linux kernel	Incomplete	This is the main Jira ticket - which links to other subtasks	LU-12511	Various
IPv6 Support	Complete	Initial support in 2.16, finalized support in 2.17	LU-18417	Various
Enforce Linux kernel coding style	Mostly Complete	The majority of checkpatch.pl warnings have been addressed. We hope to get the baseline for Lustre similar to other in-tree filesystems.	LU-6142	Various
Convert to kernel-doc comments	Partially Complete	Work is currently underway.	LU-9633	Various
Unify Lustre kernel modules	Incomplete	Reduce the total number of Lustre kernel modules	LU-17862	55153
Split userspace, compat, and kernel code	Mostly Complete	Split the core filesystem from the compatibility code needed to support older kernels	LU-18687	Various
Replace libcfs hashing code with rhashtable	In progress	Most of the users on the client have been removed; the majority of the work is server-side	LU-8130	Various
Adapt Lustre Infiniband driver to latest APIs	In progress	This is pending the transition to p2pdma API	LU-8874	Various
Remove ProcFS users	Incomplete	Most of the users on the client have been removed; the majority of the work is server-side	LU-8066	Various
Remove custom interval-tree	Complete	-	LU-11085	Various
Transition completely to folios	In progress	A lot of callbacks have been implemented; still have dependency on mm/folio-compat.c; large folio support is in-flight	LU-17916	Various
->writepage could likely be deprecated	In progress	Mostly a factor to ensure Lustre still behaves with this removed - context	LU-18675	57894
Transition to p2pdma	In progress	Lustre should use upstream p2pdma framework rather than interfacing with out-of-tree modules	LU-19848	Various
Don't use Autotools for kernel modules	Mostly Complete	Lustre kernel modules should not be built with Autotools	LU-18876	Various
Don't use inline #ifdef for kernel compatibility	In progress	The core Lustre kernel docs should be free from extraneous #ifdefs	-	Various
Ensure that Lustre builds on all support architectures	Incomplete	Builds and runs on mainline 64-bit architectures (x86, aarch64, riscv), unlikely to ever be used on 32-bit or embedded platforms.	-	Various
Ensure Lustre can build !MODULE	Mostly Complete	Fix bugs when building Lustre into the kernel image	LU-19874	Various

Proposed Transition to an Upstream-first Development Model

Background

Currently, the Lustre kernel modules are maintained as an out-of-tree driver. This driver supports a variety of vendor kernels (primarily on RHEL and Ubuntu). Code is developed first for these vendors kernels. It is later updated to support newer kernel as they are released. The core filesystem code and the compatibility code are intermixed.

For upstreaming to work, the normal development flow has to generate patches to mainline Linux. However, we must still support the older distribution kernels that most people use to run Lustre. To achieve this - we must invert the development model. Code must be developed first for the upstream kernel. Afterwards, this code will be supported on older kernels via a compatibility layer maintained by the Lustre development community. These next sections provide a high-level overview and defines a clear roadmap with tangible milestones on our path to upstream. This transition will occur in stages and will proceed in parallel with normal development - without interrupting ongoing feature work.

The timelines provided are approximate.

Tenets

There are several important considerations we must account for when undertaking this work (in order of importance):

• Mainline Linux is the source of truth - Every Lustre release must be derived from a mainline Linux release. Code change to Lustre should target mainline Linux first - and later be backported as needed. We should not block upstream improvements to facilitate backporting.

• Do not complicate the process of contributing to Lustre - Lustre has an active developer community and a large amount of pre-existing test infrastructure. Our existing processes have worked well. We should maintain the beneficial aspects of our existing workflows while transitioning to an upstream-first model.

• Integrate with the wider filesystem community - We should strive to share Lustre's improvements and advancements with the wider filesystem community. We should regularly collaborate with others in the community to facilitate kernel-wide improvements.

[I] Separate the kernel code, compatibility code, and userspace code

ETA: June 2026

The Lustre tree should be reorganized to have a clear separation of concerns:

lustre/            -> Lustre filesystem kernel modules
lnet/              -> Lustre Networking kernel modules
lnet/debug/        -> Lustre debugging code
lustre_compat/     -> Kernel backwards compatibility code
tests/             -> Regression tests
utils/             -> Userspace tools

The functional components of libcfs/ will be split into lustre/, lnet/, and debug/. The kernel backwards compatibility components would live in lustre_compat/. Centralizing the compatibility code makes it easier to maintain and update and allows us to start removing the compatibility code (and #ifdefs) from the modules themselves. lustre_compat/ will be compiled into libcfs.ko. The debugging code in debug/ will be compiled into lnet.ko (or perhaps a standalone module).

The compatibility code will provide interfaces that mirror the upstream kernel-tree. After a new upstream kernel (with Lustre included) is released, we will update the compatibility layer as-needed to support that release on older kernels. A user of Lustre could either use the upstream kernel as-is with the in-tree Lustre modules - or they could compile and use those same modules on an LTS kernel release via the compatibility layer.

[II] Get lustre/ and lnet/ to natively compile on a mainline kernel

ETA: August 2026

Once the compatibility code is isolated, we must get lustre/ and lnet/ to natively compile on a mainline kernel - without any Autotools magic, #ifdefs, or lustre_compat/ layer.

This would be enforced by adding build validation to each patch submitted to the Lustre Gerrit. The kernel version would be pinned in the Lustre build scripts and we'd periodically update it and fix any new build failures.

Once this is achieved, we'll have a clean, idiomatic, mainline Linux client and server that can be run on older distributions via a compatibility layer.

[III] Move lustre/ and lnet/ to a separate kernel tree

ETA: February 2027 (This would immediately precede submission for inclusion)

Transition to maintaining lustre/ and lnet/ as a series on patches on top of a mainline kernel release. At this point, we'll generating patches to mainline Linux while retaining the ability to support older distro kernels via lustre_compat/. Similar to the previous step, we periodically rebase our Lustre patch series - fixing lustre_compat/ as needed.

This is the only step that requires a significant change the Lustre development workflow - patches would have to be split and sent to two different repositories. This step will be delayed until we're ready to submit Lustre upstream.

[IV] Submit the patch series for inclusion

ETA: February 2027

Once we are comfortable with the above process, we can submit the initial patches to add Lustre support to the kernel. Our normal development flow will generate a batch of patches to be submitted during each merge window. After the merge window, we can focus on testing and making sure that our backport to older distro kernels is still functional.

FAQ

Who will actually run the Lustre code in mainline Linux?

Everyone who uses Lustre would prefer that it is available via their existing kernel. Releases for older distros will be a combination of the upstream Lustre combined with lustre_compat/ and whatever stuff the kernel won't allow.

What will a Lustre release look like?

Userspace tools would be available separately from the kernel modules for users who use Lustre from the mainline kernel. For users with older kernels, we would generate packages/tarballs by combining an upstream Lustre release from mainline along with lustre_compat/ and the userspace tools. Vendors and third-parties can base their versions of Lustre on those packages/tarballs. Every time a new kernel releases - new Lustre release packages/tarball will be created. Lustre LTS releases can center around the LTS kernel releases.

How will we validate that lustre/ and lnet/ build on mainline before upstream submission?

A bot, ktest, will perform minimum build, boot, and mount testing for Lustre clients and servers on the latest mainline kernels. We will investigate integrating with KernelCI in the future.

Does anyone else have a similar model? Does this even work?

DRBD was upstreamed previously and maintains an out-of-tree copy of this code for support on LTS kernels. AMD GPU also seems to have a similar approach. We hope to talk to other developers working in a model similar to this.

Testing

Currently, ktest is used to validate that Lustre continues to build and run when integrated with the latest mainline kernels. In the future, it will also validate various kernel configurations and architecture builds. It will also perform various static checks and validations.

Lustre also has extensive build and testing against LTS kernels, as well as multiple static analysis tools checking the patches before integration.

Past Talks and Coverage

This section covers previous talks and coverage about the Lustre upstreaming process.

Lustre Administrators and Developers (LAD)

LAD 2022: Native Linux client Status - James Simmons

LAD 2020: Linux Lustre Client State - James Simmons

Lustre User Group (LUG)

LUG 2026: Upstream Efforts Progress - James Simmons

LUG 2025: Lustre Upstreaming Efforts - James Simmons

LUG 2024: Native Linux client Status - James Simmons

LUG 2019: Lustre - A view from the outside - Neil Brown

LSF/MM/eBPF

Lustre Upstreaming

Linux Weekly News (LWN)

Getting Lustre upstream

Will staging lose its Lustre?

Mailing List Archives

This is a collection of mailing list threads of interest - any useful discussion related to upstreaming Lustre.

Lustre Upstreaming Project Update (2026)

LSF/MM (2025)

Discussing Lustre Upstreaming with Lustre Developers (2025)

Lustre removed from staging