5 ms·

But why? WSL1 was something like wine but reverse, but WSL2 is actually linux.

temac 6y ago
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
cesarb 6y ago
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.
tremon 6y ago
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).
- magicalhippo 6y ago
  I recall ext4 had[1] some issues[2] with data loss due to unclean shutdowns. I assumed that had all been fixed by now, but yeah, these things can get tricky fast. [1]: https://lwn.net/Articles/322823/ https://lwn.net/Articles/322823/ [2]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/...
- bmurphy1976 6y ago
  Huh, interesting. I run a variety of linux based services at home. For years I ran them on a Hyper-V VM (because my computer was technically my gaming machine). I only recently migrated everything to a cluster of Raspberry Pi devices. I used to have occasional problems with this setup, and it was always some kind of drive corruption or mounting issue. I wonder if this is related?
- the8472 6y ago
  Virtualbox has (had?) similar issues in certain configurations where it maintains a small write cache and doesn't honor IO barriers which lead to journaled/cow filesystems reporting an inconsistent state that should have been prevented by journaling.
- merb 6y ago
  > Hyper-V service is shutdown as far as I know when wsl2 is actiavted, hyper-v runs as type-1 and linux, windows are virtual after activating it. thus if it crashes, you get a bsod
dehrmann 6y ago
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.
- loeg 6y ago
  Yeah; Windows had something like that, too. It was WSL1 (or just "WSL"). I also tend to think that was the better approach.
  - bonzini 6y ago
    It didn't extend to use cases like containers, that would have basically required MS to rewrite large parts of the Linux kernel's core code for namespaces, mount points etc.
    - loeg 6y ago
      Sure. Running a Linux VM (WSL2) just to use containers seems to kind of defeat the point, though. You might as well just run your containers in VMs.
      - bonzini 6y ago
        The use case is for developers to use their Linux tools with Windows integration. WSL1 only did the latter half well, "traditional" VMs only did the former. WSL2 does both, however that brings both advantages and disadvantages of VMs.

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

cesarb 6y ago

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.

tremon 6y ago

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).

magicalhippo 6y ago
I recall ext4 had[1] some issues[2] with data loss due to unclean shutdowns. I assumed that had all been fixed by now, but yeah, these things can get tricky fast. [1]: https://lwn.net/Articles/322823/ https://lwn.net/Articles/322823/ [2]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/...
bmurphy1976 6y ago
Huh, interesting. I run a variety of linux based services at home. For years I ran them on a Hyper-V VM (because my computer was technically my gaming machine). I only recently migrated everything to a cluster of Raspberry Pi devices. I used to have occasional problems with this setup, and it was always some kind of drive corruption or mounting issue. I wonder if this is related?
the8472 6y ago
Virtualbox has (had?) similar issues in certain configurations where it maintains a small write cache and doesn't honor IO barriers which lead to journaled/cow filesystems reporting an inconsistent state that should have been prevented by journaling.
merb 6y ago
> Hyper-V service is shutdown as far as I know when wsl2 is actiavted, hyper-v runs as type-1 and linux, windows are virtual after activating it. thus if it crashes, you get a bsod

dehrmann 6y ago

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.

loeg 6y ago
Yeah; Windows had something like that, too. It was WSL1 (or just "WSL"). I also tend to think that was the better approach.
- bonzini 6y ago
  It didn't extend to use cases like containers, that would have basically required MS to rewrite large parts of the Linux kernel's core code for namespaces, mount points etc.
  - loeg 6y ago
    Sure. Running a Linux VM (WSL2) just to use containers seems to kind of defeat the point, though. You might as well just run your containers in VMs.
    - bonzini 6y ago
      The use case is for developers to use their Linux tools with Windows integration. WSL1 only did the latter half well, "traditional" VMs only did the former. WSL2 does both, however that brings both advantages and disadvantages of VMs.