The problem is likely not in the Ext4 code, but in the block I/O driver (which is Hyper-V specific, IIRC) or even in Hyper-V itself. Several reports mention Windows shutdowns, sleep or hibernation, so it may be a simple unclean shutdown of the VM.

A bigger problem would be if Hyper-V is either ignoring memory barriers, or caching writes to the disk and losing them when the Hyper-V service is shutdown. But that would likely affect more than just WSL, so we'd have seen the problem sooner (or so I vehemently hope).

That's probably the cause.

WSL2 being Linux means that, unlike WSL1 which directly uses the host NTFS filesystem, it's probably using an emulated block device to hold its filesystem. If that emulated block device doesn't correctly honor write barrier requests from the Linux kernel, it could explain the corruption.

Wild guesses:

* the kernel is not properly shutdown (and sometimes some buffers are not flushed)

* the virtual block device and/or its linux driver has bugs

FreeBSD has native support for Linux binaries by mapping system calls, and it's fairly reliable when it works. What's nice is that when it works, it works, adding support for system calls improves coverage, and since underlying things like the FS aren't virtualized, it tends to be pretty reliable.