With Asia in place, the main inhabited continents are now covered end-to-end, with one outstanding gap: the very far north of Canada. Antarctica is still on the table as the seventh and final continent, but whether it ships will depend on whether there is enough demand to justify the production work and whether we can keep the quality bar where it needs to be at those latitudes. We will revisit that decision later in the year.

A remaster phase next

With the global coverage loop almost closed, focus shifts away from new ground and onto the older packages. The next phase of work is bringing North America, South America, Europe Part 1, Africa Parts 1 and 2, and Oceania up to the current production standard: a clean ZL16 baseline and the updated XP12 water bathymetry mask settings.

The packages built before we settled on a single zoom-level story (covered in the previous roadmap post) still carry the older mixed-zoom and pre-XP12 bathymetry shape. Remastering them brings the visible quality and behaviour of those regions into line with what Asia and EU-2 already deliver, and it removes the awkwardness of telling new pilots that some of the older packages are “good but slightly different”. This is unglamorous work, but it is what makes the global footprint feel like one product rather than a sequence of generations.

On the XEarthLayer app

A short word on the app side. A 0.4.7 release is likely coming in the near future to tidy up a handful of final pieces left over from the 0.4.x line. These are small reliability and polish items rather than new headline features. After that, 0.4.7 will be the last release on this version, and work on 0.5.0 will start in the summer. We will write up where 0.5.0 is heading closer to the time.

A short break

On a personal note: I will be taking a break between now and July, travelling with family and getting some rest. Scenery production and most app work will be quiet during that window. Community channels will still be there, but expect slower responses than usual. Back at it properly in July, and thanks as always for sticking with the project.

Grab the latest build from the downloads page or straight from the GitHub release.

A more useful setup wizard

xearthlayer setup has been the recommended onboarding path for a while, but it left a lot on the table. It asked you for a cache directory and then handed you a fixed 40 GB recommendation regardless of how much disk you actually had, and it never mentioned that you could offload DDS encoding to a secondary GPU. New users were unlikely to discover those settings on their own, and a few wizard runs ended with people manually editing config.ini afterwards anyway.

This release reworks the wizard around what your hardware actually looks like. The cache step (#154) now asks for the disk budget with a default that is 25% of free space at your chosen cache directory, floored to the nearest 10 GB. The DDS-to-chunks ratio and the memory cache size are prompted in the same step, with the memory default sized as RAM ÷ 12 clamped to a 500 MB to RAM ÷ 4 band. That formula is intentional: the memory cache is a small request absorber, not a working set holder, because the DDS disk cache is what actually holds the working set of tiles. The previous tiered defaults handed out memory cache sizes that were several times larger than the absorber actually needs.

There is also a new step for DDS encoding (#153). When two or more GPU adapters are detected, the wizard offers to offload encoding to a secondary GPU and warns explicitly against picking the GPU that X-Plane uses for rendering, since that path causes frame drops rather than buying you anything. Single-GPU systems silently keep the safe ISPC default. Adapter enumeration runs behind a spinner because wgpu can take 10 to 30 seconds probing drivers on multi-GPU hosts, and silence there used to look like a freeze.

If you are using a third-party overlay scenery package such as SimHeaven or Prefab Objects and have been fighting with overlay collisions, there is also a new packages.disable_overlays runtime control (#152). When set to true, xearthlayer run removes XEL’s consolidated overlay symlink folder from Custom Scenery on startup. Your overlay packages stay downloaded and cached locally; only the symlink that X-Plane reads is suppressed. Flip the flag back to false and restart, and the overlays come back without re-downloading anything. It is deliberately a runtime control rather than a download-time one, so you can A/B between XEL overlays and a third-party set without paying the bandwidth cost each time.

Package installs you can actually trust

A few related defects on the install path got cleaned up at the same time.

The big one was that a single failed part download could quietly hang an install (#187). Previously, when a part exhausted its retries, the rest of the workers would keep running and the user got a process that needed Ctrl-C to recover, often with no clear explanation of what had gone wrong. The orchestrator now sets a shared abort flag on the first hard failure and other workers exit at their next abort check. The temp directory holding partial downloads is wrapped in a guard that wipes it on every exit path, including panics, so you no longer end up with leaked partial files in /tmp. The user-facing error names the part that failed, the underlying error message, and a count of any other parts that failed before the abort cascade finished. Same goes for concurrent_downloads = 1 users, who used to hit a separate code path with no per-part retry and no progress reporting; that path is gone now and everyone goes through the same single semaphore-bounded implementation.

The installer also now does a pre-flight disk space check (#188). After the package metadata comes back from HEAD requests but before any bytes hit the network, the installer asks “is there enough space at packages.install_location for this?” and either proceeds or fails fast with an actionable error message. This particularly matters for atomic distros like Bazzite, Silverblue, Kinoite, and SteamOS, where df / reports 100% as the steady state because the rootfs is intentionally sized to its content. Diagnostics now annotates that line as “normal on atomic distro” when it detects an ostree-deployed root, and it reports cache and packages locations with available bytes alongside used so you see the number that actually matters.

And finally, file-level logging now initialises for every CLI subcommand instead of just run (#194). If a packages install failed in the past, xearthlayer.log was empty. It is no longer empty. Structured tracing across the install pipeline emits INFO events at every stage transition (metadata, download, reassembly, extraction, completion) and DEBUG/WARN/ERROR around per-part attempts and retries. The next time something goes wrong on someone’s install, the log file is the first place to look.

A single source of truth for GPU detection

While building the wizard’s GPU step, three places in the codebase turned out to be doing the same wgpu::Instance::new + enumerate_adapters dance with their own slight format differences: the encoder, the diagnostics report, and (newly) the wizard. They have been collapsed into a single system::gpu module (#198) that everyone now calls. The wizard’s adapter-to-config-string mapping (config_value) and the encoder’s config-string-to-adapter mapping (find_adapter) are mathematical inverses, and they are now locked together by a round-trip property test that catches any drift if either side changes.

This is mostly invisible to users, but it is the kind of consolidation that matters for the next person who has to add a new GPU device type or change the keyword the encoder accepts. The selector keyword (integrated or discrete) is preferred when the GPU type is unique within the detected set, and the adapter name substring is used otherwise. Dual-discrete render farms get a config value that names the specific card.

A handful of smaller cleanups went in alongside: sensitive credentials in provider.google_api_key and provider.mapbox_access_token are now masked as xxxxxxxx in xearthlayer config list so the command output is safe to paste into bug reports (#162), with the diagnostics report’s redaction sharing the same predicate so the two surfaces stay in lockstep. The Google provider tile session parser was also rewritten on serde (#163), which correctly rejects malformed responses that the previous string-search parser would silently misinterpret.

Upgrading

Binaries are on the downloads page. Configuration files remain compatible; there is nothing you need to change on your end to upgrade. If you do want to take advantage of the new wizard prompts on a host you have already configured, xearthlayer setup will offer to back up your existing config.ini and reconfigure from scratch. Existing config keys are preserved when compatible.

If you hit anything unexpected, the Discord and GitHub issues are the fastest way to reach us. Thanks as always to everyone running pre-release builds and sending logs back.

Scenery System: State of the Union in X-Plane 12.4

The present scenery system used by X-Plane today has been with us for around twenty years. The resolution and fidelity of the system assets have improved significantly over that time as computers have become more capable. At the core however, the DSF framework X-Plane uses today is fundamentally no different from what has come before.

The foundation is simple. X-Plane scenery is packaged in one by one degree tiles, projected using the Web Mercator method to populate the Earth with cities, rivers, mountains, oceans, trees, roads, railways and very importantly, airports. The base DSF file for each tile provides the description of all of the pieces needed to build this slice of the world, from the base mesh which describes the triangles needed to represent the ground in 3D space, to the textures, land-class type and objects that exist on the tile.

Readers familiar with this project will know that XEarthLayer intercepts the references of textures as they are requested from disk in order to inject the orthophoto scenery at runtime within the world X-Plane is painting.

X-Plane loads these tiles into the simulator using a relatively simple sliding window model. When the sim loads into a location in the world for the first time, X-Plane loads a large area around the starting position for the aircraft, usually around four by three tiles in size. Once the current twelve tile area is loaded, the simulator then waits until the aircraft reaches an invisible boundary that is approximately one degree from the edge of the loaded area in either latitude or longitude.

Once that boundary has been crossed X-Plane begins loading in the next set of rows (latitude) or columns (longitude), consisting of one degree square tiles. X-Plane usually loads three of the next rows or columns of tiles ahead of the aircraft.

As part of the development of XEarthLayer, we were able to understand this loading method in depth thanks to the visibility the FUSE mount provides into what X-Plane requests from the file system at any given time. A white paper describing this in detail is published in this project’s GitHub repository.

Streaming Orthophoto Scenery Challenges

The current system X-Plane uses to load scenery in blocks of rows or columns (or both in some edge cases) was not designed with streaming orthophoto scenery in mind. It clearly assumes that the resources it needs are going to be on a local disk, and of moderate size.

Orthophoto scenery, even at modest zoom levels, requires a lot of data. At zoom level 16, X-Plane will load in the order of 12-15 gigabytes of image data in DDS BC1 encoding to populate the world. That is a lot of data to load from disk into VRAM in a short amount of time, while flying. If the streaming orthophoto provider is slow to provide the data, or stalls then X-Plane will start to stutter and can even freeze until the data necessary to paint the scene ahead of the aircraft is available.

This is something I have experienced in the sim when using AutoOrtho and Map Enhancer. XEarthLayer has received a lot of engineering focus on eliminating these stutters and freezes, and even we experience them on occasion when the cache has not been able to warm itself fully in time.

The problem is purely the volumes of data required by orthophotos and the ability to deliver that to the sim quickly. The way X-Plane loads tiles today makes this a significant challenge to avoid stutters at the loaded area boundary. Even with the recent improvements to X-Plane’s scenery loading system in 12.4 to introduce multi-threaded scenery loading, stutters can still be experienced on occasion.

The X-Plane team are also aware of this and have already signalled a significant change is coming.

Enter Raster Data Tiles

We are all raster-farians now - Ben Supnik

In an official X-Plane developer blog post published in 2024, Ben Supnik from Laminar Research clearly stated the new direction the base scenery system in X-Plane is heading in: enter Raster Data Tiles.

A Raster Data tile can be thought of as a two-dimensional array, like an image, that contains information about the area it represents. These can be layered on top of each other, so one layer can represent elevation, another vegetation, land class, water, networks (roads, rail, power), object class and anything else developers can think of. A Raster Data tile can include a layer that is purely a color map, albedo, specular and so on to create complex layers of color information that can be rendered in real time. Those maps can contain ortho-photos if desired.

This is a major departure from the current system, where all of the scenery information other than textures is described in the DSF and supporting files as vectors. Vectors have some advantages, especially when it comes to the amount of data required to describe a shape when compared to raster data.

Vectors have been historically good for flight sim scenery description because the trade-off made was to keep the scenery description as small as possible at the expense of overall visual fidelity. This indexed on keeping the simulator performance good while running on systems with restrictive hardware constraints — smaller disk drives and less memory. For many years this was fine as the rendered world that X-Plane produced was as good as it needed to be and certainly held its own against the competition.

This approach does have challenges when you want to change the level of detail in flight. Any change in the rendered fidelity of vectors in DSF tiles usually result in very noticeable visual artifacts like tears in the scenery. In reality this means the 3D mesh is locked at the level of detail provided by the tile regardless of any optimizations available due to distance from the camera. All level of detail savings are found in scenery objects and textures.

With the progression of PC hardware, fast internet connections and graphics cards with main-computer levels of memory, the landscape has changed significantly in the last decade. Modern PC hardware is capable of storing gigabytes of data in memory to describe scenes. The speed of internet connections has also significantly increased, allowing for more data to be downloaded quickly. The advancement of PC hardware means that the Laminar team can re-evaluate the trade-offs they want to make when rebuilding the scenery system.

If you have used Google Earth or Apple Maps to view the 3D world with photo scenery, you have experienced Raster Data Tiles in action. You will also understand how performant they are even when presented on a mobile phone. The entire Earth can be shown in a single frame, and then seconds later you can be 1000ft above the streets of San Francisco. The transitions are seamless, rendered at 60 frames per second or better. This is what X-Plane is aspiring to deliver in the future state. As Ben so eloquently wrote in his blog post, for the base mesh, X-Plane is aiming to use all raster tiles, all the time.

Implications for XEarthLayer in a Raster Data Tile World

The information shared so far by Ben and the Laminar team on the direction of travel for the future state of X-Plane scenery is fascinating. I can foresee many interesting features and functions that will help scenery content creators paint a far more convincing world in the simulator. At the same time this is a huge amount of work for the team. It will require a complete reimplementation of the foundational scenery system, as well as updating or rewriting the supporting tooling such as WED. It is therefore no surprise the team have been largely quiet on this subject since the 2024 announcement.

With the information shared so far it is impossible to predict the precise nature of the new scenery system, or what hooks or apis will be provided to third parties to further enhance the environment. Therefore everything presented here is pure conjecture and subject to change in the future. Given the information shared so far we can make a few assumptions and predictions about the future state of X-Plane scenery.

Assumption 1: Orthophoto Scenery will be supported in the future

The most important assumption is that orthophoto scenery will be supported in this new system. Ben called it out specifically in his blog post, and we are assuming that the ability to provide photoscenery tiles to this system will remain. That bodes well for the future of XEarthLayer.

Assumption 2: Scenery will be streamed into the simulator as needed

The second assumption we will make, which is unconfirmed but we are reasonably confident about, is that scenery will be streamed into the simulator on demand at a given level of detail rather than loaded in blocks of columns and rows as it is today. The specific function of how that works based on the view point is unknown, but we are confident X-Plane will adopt a loading method that more closely aligns with Google Earth and Apple Maps.

This also bodes well for XEarthLayer as the system is already designed to support this dynamic loading model today.

Assumption 3: First-party Scenery API for developers

A third assumption we are less confident about but will put out there is that there will be some form of API provided by X-Plane to developers to interact with scenery. We can imagine that hooks will be provided so that third-parties can provide Raster Tile data at any layer during runtime.

If this turns out to materialize it will have some impact on XEarthLayer. For the most part it will simplify our system by negating the need for the FUSE interception layer in our architecture. We would very warmly welcome this change, should anyone from Laminar Research be reading this! Removing the FUSE layer would also increase performance of the entire system considerably by removing the repetitive transit from user space to kernel space and back again for system IO calls.

Should this not materialize however, we are reasonably confident we will be able to use the existing approach based on what we know today.

Assumption 4: Better interoperability between third party airports and global scenery

The final assumption that we are very confident about because Ben provided this as an example in his post, is that using Raster Tile data will eliminate a major issue that has plagued orthophoto scenery providers since the beginning — that is, third party airports overriding the orthophoto tiles.

To the simulator pilot, this results in loading into an airport provided by a third party scenery developer and discovering that the area covered by the one by one tile around the airport does not have any photo scenery. Only when you fly away from the airport do you discover the photo scenery again, presented with a very hard and immersion destroying boundary between the two. The current scenery implementation makes this almost impossible to mitigate against, unless the third party designer provides their own complete orthophoto tile.

In the new system presented by Ben it will be relatively simple to blend the elevation data and any other provided layers with the global scenery using many existing methods for combining data of this kind. After all, we have been blending images successfully for many decades with Lanczos, Gaussian and many more mathematical models for resampling and combining image data. They can all be used for this use case as well. This removes the need to try and do complex 3D geometry merging and smoothing operations that seldom work out well.

This will enable all third party scenery and airports to coexist with everything else present in world without them having to ship their own complete orthophoto tiles, providing a seamless and invisible transition when rendered in the simulator environment.

For XEarthLayer this change will probably require zero effort on our part to support, but will be a nice free enhancement for all users of X-Plane regardless of whether they use orthophoto scenery.

There is real work ahead for us when Laminar reveal more, but we are not waiting. We are already laying the groundwork for whatever the new scenery system looks like by splitting the monolithic XEarthLayer application into smaller composable modules, building strong contracts between the layers, and exposing third-party API hooks so others can plug additional behaviour into the processing pipeline. Whichever of the assumptions above turn out to be reality, that work will let us move quickly when the picture sharpens. When Laminar share more, we will follow up with concrete details on how XEarthLayer will support the new scenery environment.

It is safe to assume that XEarthLayer and X-Plane will remain compatible long into the next generation of the simulator.

What is in production now

With Europe filled in, focus shifts to the rest of Asia. That covers a long list of countries currently in production: Russia (the asian portion), China, Mongolia, the Central Asian “-stans”, Iran, Iraq, Kuwait, the UAE, Qatar, Saudi Arabia, Jordan, Syria, Israel, Palestine and the West Bank, and India, among others. Once Asia is wrapped, Antarctica comes in as the seventh and final continent, closing the global coverage loop.

Russia is, predictably, the hardest piece of this. It is just enormous, and even chopping it into producible chunks is a non-trivial planning exercise on its own, the splits have to make sense as downloads, render reasonably in X-Plane, and not leave ugly seams across regions that real flights routinely cross.

That production work also fed back upstream. While chasing stability problems with very large area generation, we landed a fix in Ortho4XP that improves reliability when producing the kind of huge regions Russia forces on us. It is a small contribution, but it makes the rest of the Asia work materially less painful, and anyone else producing scenery at that scale benefits too.

Smaller packages

One of the biggest pieces of feedback from EU and the larger regional packages has been disk pressure. The current shape of things asks users to keep up to ~250 GB free just to install. That is a non-starter for a lot of laptop pilots and even some desktop setups, and it discourages people from trying packages outside their primary flying area.

The plan is to cap individual downloadable packages at ~20 GB going forward. North America, Asia, Europe, Africa, and Antarctica will all be reshaped into smaller collections under that cap. Users should land closer to ~50 GB free required to install, picking up only the slices they actually fly. The existing large packages will be reworked to match.

7z compression

Future packages will ship with 7z (LZMA2) compression instead of the current format. The realistic savings depend on what is inside any given package. Already-compressed imagery does not give up much regardless of algorithm, but the metadata and uncompressed payloads should see meaningful gains. The working estimate is roughly another third off typical package size, which we will firm up once the first 7z-built packages go through the pipeline.

A clearer zoom-level story

Today, most packages mix ZL16 and ZL18. Broad ZL16 coverage with ZL18 patches around airports. Anyone who has flown a few hours over a covered region knows the visible side effect: a striping seam where the two zoom levels meet, usually visible on approach into a covered field. That artifact is not a bug in any single package; it is a consequence of mixing two zoom levels in one footprint. The striping deserves its own focused write-up later, with screenshots and the geometry behind it.

The fix is to commit to a single zoom level per package and build out three tiers:

• ZL14 — SD. Aimed at pilots running 4–8 GB VRAM GPUs and anyone on a metered or slower connection. Lower bandwidth, lower VRAM pressure, still a meaningful step up from default scenery.
• ZL16 — HD. The mainline tier. Comfortable on anything with 12 GB of VRAM or more. This becomes the default global option.
• ZL18 — UHD. Future-proofing for high-end setups, likely a later-in-2026 effort once the rest of the optimisations are in place. Expect very high data usage; the working guidance is a 5 Gbps+ connection and a 32 GB VRAM GPU.

Single-zoom packages also remove the striping artifact as a side effect, because a package can no longer disagree with itself about how detailed a given area should be.

SimHeaven X-World Pro

Finally, SimHeaven X-World Pro is on the way, and XEarthLayer is preparing support for it. Concretely, that means a configuration option to suppress XEarthLayer’s own overlays in scenarios where X-World Pro is providing them — cities, landmarks, national parks, monuments — so the two products complement rather than fight each other.

That is the day-one shape of the integration. Once X-World Pro actually ships and we have hands on it, the goal is tighter coordination beyond just “stay out of each other’s way”, but it is hard to predict what that looks like in detail until it is in front of us. The headline is that XEarthLayer and X-World Pro are designed to be complementary upgrades to X-Plane, not competing ones, and the configuration plumbing will be there from the moment X-World Pro is available.

More to come as each of these lands.

Grab the latest build from the downloads page or straight from the GitHub release.

The long-haul story

The work that drove this release came out of a flight log from a long-haul out of Vienna. Somewhere past the second hour, prefetched regions started slipping into a state the system could never recover from, marked as in-progress forever, never flipping to prefetched, and serving stale data back to X-Plane.

Digging in turned up three interacting defects at once:

• Regions were being marked InProgress before the tile submission even came back. Anything that failed silently was invisible to the scheduler.
• The cached_tiles shadow set, the in-memory guess of what was on disk, was drifting badly, tracking only about 6% of the tiles that were actually cached.
• DDS disk cache look-ups were being performed with chunk coordinates instead of tile coordinates. The lookup returned false every single time, silently.

On a long flight they compounded into permanent dead regions. The fix (#172) defers the in-progress mark until the submission is confirmed, replaces the shadow set with authoritative DDS disk cache queries, and corrects the coordinate mismatch.

Prefetch, unified

Tracking down the long-haul bug meant pulling the prefetch code apart, once in there it was clear the ground and cruise paths had drifted into two different shapes of the same problem, providing two code paths to solve the same problem.

The old ring-based GroundStrategy is now gone. In its place is a symmetric PrefetchBox that both on the ground and in flight phases share. Ground prefetch uses a fixed extent with symmetric bias (0.5); cruise prefetch uses a speed-proportional extent with a heading bias (0.8).

The debug map now reads from the same source of truth. The coordinator computes prefetch bounds once per cycle and publishes a BoxBoundsSnapshot; the map renders that snapshot verbatim. No re-computation, no drift between what you see on the map and what is actually being requested.

Region colors in the debug view are also cleaner: yellow (InProgress) until every tile in a region is verified on disk, green (Prefetched) once it is, and a new orange (Mixed) state when FUSE has started serving tiles from a prefetched region.

Clearer cache metrics in the Terminal UI

The combined “Disk” line in the cache widget was hiding the thing you actually care about: how often X-Plane’s requests were being served from local disk. The TUI now splits that into three tiers; Memory, DDS Disk, and Chunks; each with its own progress bar and hit/miss counts (#166). Flight testing consistently shows DDS disk hit rates over 93%, which had been lost in the noise of chunk-level traffic.

While in there, we also fixed how the Memory and DDS Disk tiers count hits (#171). They used to aggregate every cache read, including prefetch and prewarm. On a long flight with a full memory cache, hit rate could read around 47% because prefetch misses were overly influencing the denominator. The fix tags events by RequestOrigin and renders FUSE-only rates for the tiers where it matters. The Chunks tier still uses aggregate because there is only one code path reading chunks anyway.

Another small interface fix; the queue column in the TUI now shows oldest jobs at the top and new ones at the bottom, matching how you’d naturally read a processing pipeline (#165).

A gentler default for executor concurrency

executor.max_concurrent_jobs now defaults to num_cpus / 2, down from ceil(num_cpus × 0.75). This halves the CPU pressure prefetch puts on X-Plane during heavy activity. Flight testing settled on this as the sweet spot between prefetch throughput and keeping your frame rate intact. If you have been running a custom value, this change will not override it.

Upgrading

Binaries are on the downloads page. Configuration files remain compatible; there is nothing you need to change on your end. If you hit anything unexpected, the Discord and GitHub issues are the fastest way to reach us.

Thanks to everyone who flew the pre-release builds and shared logs.

The change itself is tiny. The story is more interesting than the diff.

A small kernel default with large consequences

Linux FUSE has two settings that govern how many background read requests the kernel will keep in flight for a given file system at once:

• max_background; the ceiling for concurrent background requests. The kernel default is 12.
• congestion_threshold; the point at which the kernel starts reporting the file system as “congested” and stops sending new requests until the queue drains. The kernel default is 9.

For the kinds of file systems FUSE is most often used for, those defaults are generous. A typical FUSE file system might be serving a handful of file metadata requests, or backing a cloud drive that sees bursty but modest I/O. Twelve simultaneous reads is plenty.

XEarthLayer is not a typical FUSE filesystem. When you fly over a scenery boundary, X-Plane 12 asks for multiple DDS texture tiles all at once, fifty or more is normal in X-Plane 12.4, sometimes higher. Every one of those requests arrives through our FUSE mount. With the kernel capped at twelve concurrent in-flight requests, the remaining forty get queued. The kernel flags the file system as congested, everything stalls until the queue drains. You see it as a frame drop or a sim freeze, exactly the kind of thing scenery streaming is supposed to prevent.

The patch we provided ensures that we can unlock the full potential of the FUSE I/O throughput to handle the huge data requests X-Plane 12 can make. This will also support other FUSE use-cases that require support for a high volume of concurrent requests.

What the patch actually does

fuse3 exposes a ReplyInit struct that a file system sends back to the kernel during initialization. Before this patch, it only had one control, max_write, and the two background-related fields were hard coded to the kernel defaults.

The patch adds two optional fields:

pub max_background: Option<u16>,
pub congestion_threshold: Option<u16>,

Leave them None and nothing changes, the kernel defaults still apply. Set them, and the kernel uses your values instead. XEarthLayer now runs with max_background = 256 and congestion_threshold = 192, which is enough headroom for the worst scene transitions we have been able to produce.

This change also marks ReplyInit as #[non_exhaustive] and added a ReplyInit::new(max_write) constructor. That is a small, one-time migration for existing users, struct literals have to become constructor calls, but it means future additions to ReplyInit will not be semver-breaking. For a crate that sits underneath everyone’s file system, that future-proofing felt worth the one-line migration.

What this means for you

If you are running XEarthLayer, nothing changes, you already had these limits applied, because our fork was doing this since v0.3.1. The 0.4.4 release is the first version that gets the same behavior from a dependency you could install yourself rather than one we maintained out-of-tree.

If you are building something else with fuse3 and your filesystem serves a lot of concurrent reads, it’s worth a look at ReplyInit::max_background and ReplyInit::congestion_threshold. The defaults are good for ordinary workloads and actively harmful for throughput-heavy ones. You will know immediately whether it matters to you.

Thanks to Sherlock-Holo for maintaining fuse3 and for merging the patch quickly. One of the quiet privileges of building on open source is that when you hit a sharp edge, the fix can go back into the thing everyone uses; and the people who run into the same problem next year will never know there was a sharp edge there at all. Another win for Open Source.