WSL distro VHDX inherited NTFS compression, fragmented to 1.59M extents, then failed writes with STATUS_FILE_SYSTEM_LIMITATION

Windows Version

Microsoft Windows 11 Pro 10.0.26200.8894 (x64)

WSL Version

2.7.10.0

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

6.18.33.2-2

Distro Version

Ubuntu 24.04.4 LTS

Other Software

The incident occurred during a write-heavy development workload, but later failures affected unrelated processes and services throughout the distro. The workload appears to have exposed the storage condition rather than caused process-specific corruption.

Summary

A registered WSL 2 distro was stored beneath an NTFS directory with Compress contents enabled. Its ext4.vhdx inherited NTFS compression. After growing to 234,370,367,488 logical bytes, the file had 1,590,869 reported VCN extents. Windows then began returning 0xC0000427 (STATUS_FILE_SYSTEM_LIMITATION) on writes/flushes. NTFS logged delayed-write data loss, VHDMP invalidated the VHD surface after a failed flush, Linux reported failed virtual-disk writes, ext4 remounted read-only, and unrelated processes began receiving SIGBUS/abort failures.

The underlying NTFS fragmentation limitation is documented, especially for compressed files. The WSL-specific safety gap is that a distro VHDX can remain registered and writable while carrying the NTFS Compressed attribute, with no visible preflight warning or guard before the failure becomes destructive.

I have not intentionally reproduced this to failure because the result is data loss. The production incident and a clean replacement provide the comparison below.

Repro / incident conditions

1. Store or register a WSL 2 distro VHDX under an NTFS directory that has compression inheritance enabled.
2. Confirm that the host file has the NTFS Compressed attribute.
3. Allow the dynamic VHDX to grow and receive sustained writes over time.
4. In this incident, the host file eventually reached 234,370,367,488 logical bytes and 1,590,869 extents.
5. Writes then failed with 0xC0000427; WSL continued surfacing the resulting virtual-storage failures inside Linux.

Expected Behavior

WSL should protect distro VHDX files from this known-dangerous host configuration. Possible protections:

• On import, import-in-place, registration, management, and/or startup, detect the NTFS Compressed attribute on a distro VHDX.
• Reject the configuration with a clear, actionable error, or safely remove/prevent compression where WSL owns creation of the file.
• Warn prominently in documentation and diagnostics that NTFS compression must not be enabled on WSL distro VHDX files or inherited from their parent directories.
• Surface a host-side storage-limitation error before users encounter unexplained Linux SIGBUS failures and an ext4 read-only remount.

Actual Behavior

Host-side evidence from the incident:

• ext4.vhdx: 234,370,367,488 bytes; attributes Archive, Compressed; not sparse.
• Parent distro directory and its parent both had Directory, Compressed, so new files inherited compression.
• fsutil file queryextents produced 1,590,869 VCN extent lines for the VHDX.
• compact /Q confirmed the VHDX was NTFS-compressed. Compression saved only about 4% (234.37 GB logical versus 224.82 GB physical).
• Windows System log contained 537 Ntfs Event ID 141 delayed-write failures over roughly 11 hours, naming the VHDX and stating that data had been lost.
• VHDMP Event ID 11 reported that the VHD surface was invalidated because a Flush operation failed with status 0xC0000427.
• chkdsk /scan logged a read failure with 0xC0000427 while examining the NTFS USN journal.
• Inside WSL, the kernel logged repeated hv_storvsc failed WRITE(10) operations; ext4 remounted read-only; PostgreSQL, shells, Node/Codex, Python, and other unrelated processes later aborted or received SIGBUS.
• The last complete application records preceded the first NTFS delayed-write event; the cross-process crashes occurred later. This points to host storage failure first, not one application corrupting the distro.

Comparison after recovery:

• A fresh uncompressed WSL VHDX on another NTFS volume is 62,531,829,760 bytes and has 548 extents.
• Its parent directory does not enable compression and the VHDX has no Compressed or Sparse attribute.
• All copied Git object databases passed strict git fsck, and quarantined SQLite state databases passed full integrity checks.

Hardware checks did not prove a physical-drive fault: Windows reported both NVMe devices healthy with zero wear, and there were no WHEA, stornvme, or StorPort errors in the reviewed 72-hour window. That does not completely clear hardware, but the exact status code, extreme extent count, compressed attribute, and Microsoft documentation make NTFS attribute/extent exhaustion the leading explanation.

Diagnostic Logs

The failing distro is no longer being run, and collecting a new WSL trace now would not capture the original event. The original VHDX and read-only recovery images have been preserved. I can provide sanitized Event Viewer exports and additional non-content fsutil/attribute output, or email privacy-reviewed logs after an issue number exists. I am intentionally not attaching full crash dumps or development/session data publicly.

Relevant Microsoft documentation

• NTFS heavily fragmented file growth limitation (compressed files are more likely to hit it): https://support.microsoft.com/help/967351
• fsutil behavior documentation notes NTFS extent limits and fragmentation risk for compressed/sparse files: https://learn.microsoft.com/windows-server/administration/windows-commands/fsutil-behavior

The report does not name implementation files, tests, or entry points. Start by locating the distro VHDX import, registration, management, and startup paths, then check how host file attributes and storage errors are handled. Done should mean a safe, actionable response to compressed distro VHDX files, with validation or diagnostics covering the agreed lifecycle points.