12 ms·

I think calling it WSL2 was a mistake. The predecessor, WSL, "just worked" and it was more a less a linux experience for most practical purposes-- and certainl

I think calling it WSL2 was a mistake. The predecessor, WSL, "just worked" and it was more a less a linux experience for most practical purposes-- and certainly better than hoary old cygwin. This caused a lot of people to believe they could just transition to WSL2, lead on by the promise of an even more performant linux experience. The documentation didn't say anything about complications from attempting this, so a lot of people just tried it as soon as they could, thinking it would go as smoothly as when they tried WSL. But nope... it many cases, it doesn't just work out of the box. There's network configuration and gateway issues, snags with vpn, and now this git repo corruption. When you look on git issues, it's just people randomly shot-gunning suggestions, some of which work, some of which don't. I think WSL2 was rushed out too early, or at least it's lacking a comprehensive troubleshooting guide to get it up and running.

pletnes 6y ago
Same difference in my experience - WSL1 git screwed up git repos for me, broke git lfs, +++. I guess it’s more of the same-ish on WSL2, just different edge cases due to different edges.
shaklee3 6y ago
I agree. I tried wsl2, and while it's nice, it has issues wsl1 didn't have. For instance, networking almost never worked until I applied a common workaround of resetting the ip stack. Wsl1 always worked fine for that. It's just not ready for primetime yet.
harikb 6y ago
File system corruption is unforgivable mistake, but FS work is really hard to get right. Even stuff like VMware corrupts shared folders ... wherever they try to bypass a driver translation layer. Just Google for “vmware shared folder corruption”
- rleigh 6y ago
  Is this the reason why they have deprecated shared folders in Workstation 16?
  - Qerub 6y ago
    I don't think they deprecated shared folders, only shared VMs (a function that enables Workstation to act as a virtualization server). Source: https://en.wikipedia.org/wiki/VMware_Workstation#Version_history https://en.wikipedia.org/wiki/VMware_Workstation#Version_his...
    - nikanj 6y ago
      That’s a shame. I have a high-powered desktop and sometimes it’s nice to work from the patio by opening a few VMs on my laptop. I get the oomph of the big box with the mobility of the laptop. To be fair, this feature always felt..rickety. But it was very nice.
      - wila 6y ago
        You can still use remote desktop for accessing remote VMs. You would be missing the remote power operations. FWIW, I am working on a product called Vimarun [0] that is aimed to replace most of that missing functionality over time. No remote power operations yet, but that will come. [0] https://vimarun.com https://vimarun.com
        nikanj 6y ago
        I'd also be missing the ability to plug in USB devices, which is very central to the work I do. RDP has some device passover support, but it's not even close to being able to replace vmware's USB support.
        wila 6y ago
        You are talking about redirecting USB via workstation as well? eg. connecting USB devices remotely to your VM? (asking as normal USB pass-through doesn't work for a shared VM, see [0]) I hadn't even considered that. Connecting USB devices remotely works well with vSphere, but never tried that with Workstation. They are going to completely removing the hostd engine from VMware Workstation. That would indeed also include that part and it is most likely not easy to get that working without hostd. [0] http://kb.vmware.com/kb/2005585 http://kb.vmware.com/kb/2005585
- dmw_ng 6y ago
  Reminds me of an infuriating old bug in VirtualBox where it wouldn't notice the size of a file had changed. Devs were working in some Windows editor then using Git within VirtualBox to commit changes, resulting in inexplicable trailing nulls and garbage turning up in the repo Took quite some time to figure out what was causing it. "Everyone is somehow corrupting files except for me, wtf?" Magic filesystem translation layers always suck
  - ficklepickle 6y ago
    I'm now in the habit of doing a git diff before every commit. Even if I don't thoroughly read the diff, I at least skim it for sanity. I can't recall what made me start doing that, but now it's a habit.
    - withinboredom 6y ago
      I do git add -up Same thing, sorta but all in one go.
- sys_64738 6y ago
  FS corruption is the worst as you lose total confidence in the product. This is a mega process escape that the WSL team would need to transparently detail why it happened, what the remedy is, and why it'll never, ever happen again.
  - AaronFriel 6y ago
    My guess is it's the result of shutting down the virtual machine that runs the Linux kernel too soon, leaving writes to the virtual hard disk in an inconsistent state. This coincides with "shutdown /r /t 0" being able to cause it as well as blue screens or power loss. And explains why I've never seen it, despite using WSL2 on insider preview builds on multiple machines daily: I almost never shut down, only for updates and new builds.
    - admax88q 6y ago
      The kernel should and can handle unexpected ahutdowns without corruption. Data loss sometimes, but not corruption.
      - ylyn 6y ago
        This is data loss. A few object files in the Git directory are truncated. Which results in a corrupted repository, from Git's point of view.
        TylerE 6y ago
        That’s corruption. Data loss would indicate an entire fs transaction getting dropped entirely - but not breaking the principle of atomic ops. A write should either happen entirely or not at all.
        stretchcat 6y ago
        Does git actually attempt to write all objects atomically?
- Someone 6y ago
  Is this file system corruption? The article isn’t 100% clear it ‘only’ loses some data writes, but it also doesn’t explicitly say files not being written are affected, directory structures are corrupted, etc. So, to me, it looks like WSL2 not completely flushing writes to the underlying file system. Bad, but not as bad as file system corruption (which could lead to losing all data on the disk)
  - Gibbon1 6y ago
    Not my area but I seem to remember bitches that Linux lies about fsync. As in it'll swear up and down that it flushed everything to disk, but it's lying. Also over the years it seems like everyone I've seen that habitually edits files remotely ends up with this sort of pain and butthurt.
  - cmurf 6y ago
    There's no enough information to know if all the reported problems are the result of the same defect. But in: https://github.com/microsoft/WSL/issues/5895 https://github.com/microsoft/WSL/issues/5895 The first instance of a problem is: [ 1.956835] JBD2: Invalid checksum recovering block 97441 in log And that's corruption that leads to log replay failing, i.e. rejecting it because honoring the replay in the face of checksum errors could make things much worse. Subsequently mount fails: [ 21.151232] ERROR: MountExt4:1659: mount(/dev/sdb) failed 5 That's good because the purpose of journal replay is to make the file system consistent following a crash/power fail. And if the file system is dirty, replay is called for, but can't happen due to a corrupt journal, so now an fsck is required. i.e. it is in an inconsistent (you could say partly broken) state and needs repair. I haven't seen syslog/systemd journal for other cases to know if there's instances of ext4 log replay that succeeds, but with missing files. That's not file system corruption, even if it leads to an inconsistent state in a git repository (or even a database). But this is still concerning, because to get a situation where log replay is clean but files are missing suggests an entire transaction was just dropped. It never made it to stable media, and even the metadata was not partially written to the ext4 journal. qemu-kvm has a (host) cache setting called "unsafe". Default is typically "none" or "write back". The unsafe mode can result in file system corruption if the host crashes or has a power failure. The guest's IO is faster with this mode, but the write ordering expected by the file system is not guaranteed if the host crashes. i.e. writes can hit stable media out of order. If the guest crashes, my experience has been that things are fine - subsequent log replay (in the guest) is successful, because the guest writes that made it to the host cache do make it to stable media by the same the guest reboots. The out of order writes don't matter... unless the host crashes, and then it's a big problem. The other qemu cache modes have rather different flush/fua policies that can still keep a guest file system consistent following a host crash. But they are slower. So it makes me suspicious that for performance reasons, WSL2 might be using a possibly volatile host side caching policy. Merely for additional data point, it might be interesting to try to reproduce this problem using e.g. Btrfs for the guest file system. If write order is honored and flushed to stable media appropriate for default out of the box configuration of a VM, I'd expect Btrfs never complains, but might drop up to 30s of writes. But if there's out of order writes making it to stable media, Btrfs will also complain, I'd expect transid errors which are also a hallmark of drive firmware not consistently honoring flush/fua and then you get a badly timed crash. (And similar for ZFS for that matter - nothing is impervious to having its write order expectations blown up.)
- wila 6y ago
  Interesting. I basically live at the VMware community forums and could not remember this issue... FWIW I am a user moderator down there and VMware desktop products (Workstation/Fusion/Player) has my focus and as a result I basically read almost every post that would report this issue. I just DDG'ed it and see one report from 2014 [0], ok some more from around 2008 when using google. Looks like this was resolved in 2015 as that was the last time I see it being mentioned. [0] https://communities.vmware.com/thread/485062 https://communities.vmware.com/thread/485062
- smileybarry 6y ago
  My experience was locked files or lost shared folders (VM doesn't see them until you say the magic words, aka randomly stop and start services until it works). Both happened so (relatively) frequently that I just lost confidence in the feature until version 16 where read-only folders works fine. (I stopped using it in version 9)
- mehrdadn 6y ago
  I could swear I ran into that corruption (or a similar one?) almost a decade ago. They still haven't fixed it?! It was quite reproducible too, it just happened when I transferred a large file...
k__ 6y ago
Wasn't the main purpose of WSL2 to make WSL finally usable because before v2 it had really bad IO perf?
- pletnes 6y ago
  There are other issues, too. At least at some point, absolutely no haskell based apps would run, since their stdlib used some syscall which WSL1 did not implement. Broke pandoc for me. Stopped bothering with WSL1 there and then. Other issues which colleagues encountered include abysmal performance and broken python installations as PATHs and other environment details are wildly mixed inside WSL. I just don’t understand why some people were seemingly happy with WSL1, there were so many rough edges. WSL2 is much much better in my experience, on virtually all fronts.
- resfirestar 6y ago
  Except they moved performance backwards in WSL2 for accessing files shared with Windows: https://github.com/microsoft/WSL/issues/4197 https://github.com/microsoft/WSL/issues/4197
- alerighi 6y ago
  It didn't have bad IO performance. It had the same IO performance as Windows. The problem is software that is badly written and does bad assumptions, like that continuing opening/closing files is good just because in Linux is good, that maybe true on most UNIX systems but nobody said that. I think that WSL2 is a very very bad idea, you are no longer making a POSIX subsystem of Windows, a way to use the POSIX API in the Windows kernel, without any emulation (basically the same thing as WINE), you are running a virtual machine. I would say that WSL2 performance is very bad if you work in the Windows filesystem. Sure, if you work from the WSL home directory that is mounted in a ext4 virtual filesystem performance is good, it's a VM. But this is useless, you see the main advantage of WSL over having a VM or a dual boot was integration with Windows, the ability to use bash scripts to manipulate your Windows files, the ability to launch Windows executables and pipe the output into a POSIX executable. All of that is useful if there is a strong connections between the two systems, if I can work with WSL in the same home directory as Windows where I have all my files. How is useful if before working on something (that could be a stupid thing like running a script to rename a bunch of files) I have to first copy the files that I intend to work on in the WSL home, run what I have to turn, and copy them back? And what if I want my IDE in execution in Windows with the project in Windows and I want to launch on the project bash scripts? I hope they will not discontinue WSL1! If they will discontinue WSL1, unfortunately I will have to go back to cygwin that was not great but worked mostly fine, since I need integration between Windows and Linux.
robbyt 6y ago
Rushing half-finished products out, offering little/zero support is the new Microsoft. The reason $MSFT loves open source is because they can get press hype over projects that are 75% complete (which is the main goal), and they don't even need to support it, document it, or make it actually work.
- lallysingh 6y ago
  New? Windows 95 comes to mind.
  - ConceptJunkie 6y ago
    DOS 3.0 comes to mind as well.
- corty 6y ago
  Half-finished releases haven been Microsofts SOP since forever. And especially for payware, bugs are only fixed in the next release, so you need to buy the subscription or the new release.
  - mekoka 6y ago
    Really? https://github.com/microsoft/WSL/issues/4619 https://github.com/microsoft/WSL/issues/4619 https://github.com/microsoft/WSL/issues/6069 https://github.com/microsoft/WSL/issues/6069
    - corty 6y ago
      "haven" should be "have". Sorry, cannot edit it now.
- uncledave 6y ago
  Yeah I think you nailed it there actually. That's exactly their modus operandi. What's even worse is they have managed to abstract most of the support away in this cycle. You can't get enterprise support now because they gutted that entirely. You can't get them to do anything on github because they keep moving all the projects around and erasing them all or auto closing the tickets and no one on first line support knows anything now other than how to reset a Microsoft account password.
tarr11 6y ago
Huh, I had the opposite experience trying to use wsl1 with a rails app, which required lots of workarounds. Postgres never worked for example natively. Several npm modules would fail when running webpack. wsl2 worked perfectly for these cases. I wonder if people are mounting an ntfs volume in wsl2 which is really slow and janky?
- tyingq 6y ago
  There's examples of people using the Linux filesystem and having the issue. From reading the issue and related ones, it sounds like it might be related to some sort of unpredictable unclean VM shutdown.
- cambalache 6y ago
  I develop Rails in WSL1 just fine. > Postgres never worked for example natively. That's a minor incovenience at worst. I will stay put in WSL1. If I wished a VM I would have just installed VMWare and run some Linux ISO image from it.
  - pydry 6y ago
    I mean, why not do that? I tried WSL because I thought it would be faster than a heavyweight VM. Turned out it's dog slow in comparison. Honestly don't see a use for it.
    - shawnz 6y ago
      I find the opposite, WSL1 is much faster for pretty much every usage except workloads that involve reading/writing lots of files.
      - pydry 6y ago
        The difference on I/O is enough to make WSL unusable. I wasted a day trying to figure out if I had a problem with anti-virus or something that was blocking me before realizing that WSL I/O is just... well, slow. People kept telling me to upgrade to WSL2 to solve that but the version of windows I had didn't allow it. Might have been a blessing in disguise given the data corruption bugs.
snarfy 6y ago
I was using WSL to do esp8266 development so I could use linux tools. The official esp8266 windows toolchain is based on cygwin. If I'm using something that needs a unix environment anyway, why use cygwin when you have WSL? I upgraded to WSL2 because well 2 is bigger than 1 so it must be better. But no, nothing worked. Serial ports are not supported in WSL2.
- Scene_Cast2 6y ago
  I literally spent the last couple of days getting ESP32 to work under WSL. Was not painless. You can have WSL1 and WSL2 side by side IIRC. And there are scripts out there to pipe serial into WSL2.
- sz4kerto 6y ago
  http://matevarga.github.io/esp32/m5stack/esp-idf/wsl2/2020/05/31/flashing-esp32-under-wsl2.html http://matevarga.github.io/esp32/m5stack/esp-idf/wsl2/2020/0... Here's how you can flash ESP devices under WSL2.
- yjftsjthsd-h 6y ago
  > why use cygwin when you have WSL? Well. Has cygwin ever corrupted get repos?
  - shawnz 6y ago
    No, but WSL1 (which they are referring to in that quote) also has never done that.
- Koshkin 6y ago
  Why use WSL if you have Cygwin?
hvdijk 6y ago
I don't think calling it WSL2 was a mistake. It wasn't something that was good for the users, but it had a very clear benefit for the people working on WSL: calling it WSL2 allowed them to close WSL1 issues en masse as "fixed in WSL2" and never look at them again.
- zamadatix 6y ago
  You can say "fixed in <name>" regardless if the name is numerically sequential.
  - hvdijk 6y ago
    True, but if MS hadn't presented WSL2 as a variant of WSL, any issues fixed in WSL2 wouldn't count as fixed in the WSL issue tracker. I would prefer it if their issue tracker marked these, more honestly in my opinion, as "This issue is will not be fixed in WSL, you can migrate to HVL instead" (using HVL as a hypothetical name for WSL2) with a separate HVL issue tracker.
    - andrew_ 6y ago
      A poor argument IMHO. A naming change for the sake of an issue tracker that appears to be a net negative for users is not a wise choice. Naming and branding doesn't exist to serve the project's management tools.
    - zamadatix 6y ago
      Whether they are counted as fixed in the WSL tracker is completely up to them. "Fixed, use HVL" is just as valid way to close a WSL1 issue ticket as "Fixed, use WSL2".
    - tw04 6y ago
      I guess I don't follow your point. The very reason WSL2 exists is because there were countless issues that COULDN'T be fixed with the way WSL1 was implemented. Why would they leave an issue open they fixed, just because the fix required a complete re-implementation? Furthermore why would they change the name, this is literally how they are carrying forward the functionality of WSL 1. It's still Linux on Windows, there is still a custom subsystem to allow the functionality. It is quite literally still Windows Subsystem for Linux. As documented: https://i.redd.it/po98dksksjx21.png https://i.redd.it/po98dksksjx21.png Should Mac Office not be called Office because they completely re-wrote it?
lukeschlather 6y ago
Cygwin was fast and mostly just worked. I did not find WSL to work well, WSL2 seems more usable. Still has warts but definitely an improvement.
- deleted 6y ago
  [deleted]
sys_64738 6y ago
If you drop WSL then you get confused branding of what they are. WSL1 and WSL2 make it pretty clear you're getting the Hyper-V thing for the latter and the former is a Linux sys call API layer. I'm actually surprised they can't be used together.
- javajosh 6y ago
  Those names don't imply anything about their implementation.
  - hunter2_ 6y ago
    Tangent: they imply running on Linux; a Wine substitute.
- archsurface 6y ago
  Agreed. Whatever the implementation the name indicates the next step in this solution. To do otherwise would be like naming windows95 something other than windows after windows3.1. Marketing.
- freeone3000 6y ago
  There's a few exclusive portions, like the executable load error handler that triggers ELF to load under the subsystem, and the binding of the 'bash' executable. But mostly, to prevent a great deal of confusion.
ConceptJunkie 6y ago
> and certainly better than hoary old cygwin. Say what you want about cygwin, but it never did this.
- uranusjr 6y ago
  Parent was talking about WSL1, which didn’t do this either.
throwaway201103 6y ago
The last job I had where I had a Windows desktop (about a decade ago, now) I used Cygwin extensively and never had any big issues. That includes running X11 not just shell stuff. It was quite solid.
deleted 6y ago
[deleted]
ihaveajob 6y ago
Docker support was the main reason to upgrade in my case. IIRC, WSL was missing some key functionality that made Docker unusable for my purposes. Of course I don't remember the details; all I know is I had no real choice.

pletnes 6y ago

Same difference in my experience - WSL1 git screwed up git repos for me, broke git lfs, +++. I guess it’s more of the same-ish on WSL2, just different edge cases due to different edges.

shaklee3 6y ago

I agree. I tried wsl2, and while it's nice, it has issues wsl1 didn't have. For instance, networking almost never worked until I applied a common workaround of resetting the ip stack. Wsl1 always worked fine for that. It's just not ready for primetime yet.

harikb 6y ago

File system corruption is unforgivable mistake, but FS work is really hard to get right. Even stuff like VMware corrupts shared folders ... wherever they try to bypass a driver translation layer. Just Google for “vmware shared folder corruption”

rleigh 6y ago
Is this the reason why they have deprecated shared folders in Workstation 16?
- Qerub 6y ago
  I don't think they deprecated shared folders, only shared VMs (a function that enables Workstation to act as a virtualization server). Source: https://en.wikipedia.org/wiki/VMware_Workstation#Version_history https://en.wikipedia.org/wiki/VMware_Workstation#Version_his...
  - nikanj 6y ago
    That’s a shame. I have a high-powered desktop and sometimes it’s nice to work from the patio by opening a few VMs on my laptop. I get the oomph of the big box with the mobility of the laptop. To be fair, this feature always felt..rickety. But it was very nice.
    - wila 6y ago
      You can still use remote desktop for accessing remote VMs. You would be missing the remote power operations. FWIW, I am working on a product called Vimarun [0] that is aimed to replace most of that missing functionality over time. No remote power operations yet, but that will come. [0] https://vimarun.com https://vimarun.com
      - nikanj 6y ago
        I'd also be missing the ability to plug in USB devices, which is very central to the work I do. RDP has some device passover support, but it's not even close to being able to replace vmware's USB support.
        wila 6y ago
        You are talking about redirecting USB via workstation as well? eg. connecting USB devices remotely to your VM? (asking as normal USB pass-through doesn't work for a shared VM, see [0]) I hadn't even considered that. Connecting USB devices remotely works well with vSphere, but never tried that with Workstation. They are going to completely removing the hostd engine from VMware Workstation. That would indeed also include that part and it is most likely not easy to get that working without hostd. [0] http://kb.vmware.com/kb/2005585 http://kb.vmware.com/kb/2005585
dmw_ng 6y ago
Reminds me of an infuriating old bug in VirtualBox where it wouldn't notice the size of a file had changed. Devs were working in some Windows editor then using Git within VirtualBox to commit changes, resulting in inexplicable trailing nulls and garbage turning up in the repo Took quite some time to figure out what was causing it. "Everyone is somehow corrupting files except for me, wtf?" Magic filesystem translation layers always suck
- ficklepickle 6y ago
  I'm now in the habit of doing a git diff before every commit. Even if I don't thoroughly read the diff, I at least skim it for sanity. I can't recall what made me start doing that, but now it's a habit.
  - withinboredom 6y ago
    I do git add -up Same thing, sorta but all in one go.
sys_64738 6y ago
FS corruption is the worst as you lose total confidence in the product. This is a mega process escape that the WSL team would need to transparently detail why it happened, what the remedy is, and why it'll never, ever happen again.
- AaronFriel 6y ago
  My guess is it's the result of shutting down the virtual machine that runs the Linux kernel too soon, leaving writes to the virtual hard disk in an inconsistent state. This coincides with "shutdown /r /t 0" being able to cause it as well as blue screens or power loss. And explains why I've never seen it, despite using WSL2 on insider preview builds on multiple machines daily: I almost never shut down, only for updates and new builds.
  - admax88q 6y ago
    The kernel should and can handle unexpected ahutdowns without corruption. Data loss sometimes, but not corruption.
    - ylyn 6y ago
      This is data loss. A few object files in the Git directory are truncated. Which results in a corrupted repository, from Git's point of view.
      - TylerE 6y ago
        That’s corruption. Data loss would indicate an entire fs transaction getting dropped entirely - but not breaking the principle of atomic ops. A write should either happen entirely or not at all.
        stretchcat 6y ago
        Does git actually attempt to write all objects atomically?
Someone 6y ago
Is this file system corruption? The article isn’t 100% clear it ‘only’ loses some data writes, but it also doesn’t explicitly say files not being written are affected, directory structures are corrupted, etc. So, to me, it looks like WSL2 not completely flushing writes to the underlying file system. Bad, but not as bad as file system corruption (which could lead to losing all data on the disk)
- Gibbon1 6y ago
  Not my area but I seem to remember bitches that Linux lies about fsync. As in it'll swear up and down that it flushed everything to disk, but it's lying. Also over the years it seems like everyone I've seen that habitually edits files remotely ends up with this sort of pain and butthurt.
- cmurf 6y ago
  There's no enough information to know if all the reported problems are the result of the same defect. But in: https://github.com/microsoft/WSL/issues/5895 https://github.com/microsoft/WSL/issues/5895 The first instance of a problem is: [ 1.956835] JBD2: Invalid checksum recovering block 97441 in log And that's corruption that leads to log replay failing, i.e. rejecting it because honoring the replay in the face of checksum errors could make things much worse. Subsequently mount fails: [ 21.151232] ERROR: MountExt4:1659: mount(/dev/sdb) failed 5 That's good because the purpose of journal replay is to make the file system consistent following a crash/power fail. And if the file system is dirty, replay is called for, but can't happen due to a corrupt journal, so now an fsck is required. i.e. it is in an inconsistent (you could say partly broken) state and needs repair. I haven't seen syslog/systemd journal for other cases to know if there's instances of ext4 log replay that succeeds, but with missing files. That's not file system corruption, even if it leads to an inconsistent state in a git repository (or even a database). But this is still concerning, because to get a situation where log replay is clean but files are missing suggests an entire transaction was just dropped. It never made it to stable media, and even the metadata was not partially written to the ext4 journal. qemu-kvm has a (host) cache setting called "unsafe". Default is typically "none" or "write back". The unsafe mode can result in file system corruption if the host crashes or has a power failure. The guest's IO is faster with this mode, but the write ordering expected by the file system is not guaranteed if the host crashes. i.e. writes can hit stable media out of order. If the guest crashes, my experience has been that things are fine - subsequent log replay (in the guest) is successful, because the guest writes that made it to the host cache do make it to stable media by the same the guest reboots. The out of order writes don't matter... unless the host crashes, and then it's a big problem. The other qemu cache modes have rather different flush/fua policies that can still keep a guest file system consistent following a host crash. But they are slower. So it makes me suspicious that for performance reasons, WSL2 might be using a possibly volatile host side caching policy. Merely for additional data point, it might be interesting to try to reproduce this problem using e.g. Btrfs for the guest file system. If write order is honored and flushed to stable media appropriate for default out of the box configuration of a VM, I'd expect Btrfs never complains, but might drop up to 30s of writes. But if there's out of order writes making it to stable media, Btrfs will also complain, I'd expect transid errors which are also a hallmark of drive firmware not consistently honoring flush/fua and then you get a badly timed crash. (And similar for ZFS for that matter - nothing is impervious to having its write order expectations blown up.)
wila 6y ago
Interesting. I basically live at the VMware community forums and could not remember this issue... FWIW I am a user moderator down there and VMware desktop products (Workstation/Fusion/Player) has my focus and as a result I basically read almost every post that would report this issue. I just DDG'ed it and see one report from 2014 [0], ok some more from around 2008 when using google. Looks like this was resolved in 2015 as that was the last time I see it being mentioned. [0] https://communities.vmware.com/thread/485062 https://communities.vmware.com/thread/485062
smileybarry 6y ago
My experience was locked files or lost shared folders (VM doesn't see them until you say the magic words, aka randomly stop and start services until it works). Both happened so (relatively) frequently that I just lost confidence in the feature until version 16 where read-only folders works fine. (I stopped using it in version 9)
mehrdadn 6y ago
I could swear I ran into that corruption (or a similar one?) almost a decade ago. They still haven't fixed it?! It was quite reproducible too, it just happened when I transferred a large file...

k__ 6y ago

Wasn't the main purpose of WSL2 to make WSL finally usable because before v2 it had really bad IO perf?

pletnes 6y ago
There are other issues, too. At least at some point, absolutely no haskell based apps would run, since their stdlib used some syscall which WSL1 did not implement. Broke pandoc for me. Stopped bothering with WSL1 there and then. Other issues which colleagues encountered include abysmal performance and broken python installations as PATHs and other environment details are wildly mixed inside WSL. I just don’t understand why some people were seemingly happy with WSL1, there were so many rough edges. WSL2 is much much better in my experience, on virtually all fronts.
resfirestar 6y ago
Except they moved performance backwards in WSL2 for accessing files shared with Windows: https://github.com/microsoft/WSL/issues/4197 https://github.com/microsoft/WSL/issues/4197
alerighi 6y ago
It didn't have bad IO performance. It had the same IO performance as Windows. The problem is software that is badly written and does bad assumptions, like that continuing opening/closing files is good just because in Linux is good, that maybe true on most UNIX systems but nobody said that. I think that WSL2 is a very very bad idea, you are no longer making a POSIX subsystem of Windows, a way to use the POSIX API in the Windows kernel, without any emulation (basically the same thing as WINE), you are running a virtual machine. I would say that WSL2 performance is very bad if you work in the Windows filesystem. Sure, if you work from the WSL home directory that is mounted in a ext4 virtual filesystem performance is good, it's a VM. But this is useless, you see the main advantage of WSL over having a VM or a dual boot was integration with Windows, the ability to use bash scripts to manipulate your Windows files, the ability to launch Windows executables and pipe the output into a POSIX executable. All of that is useful if there is a strong connections between the two systems, if I can work with WSL in the same home directory as Windows where I have all my files. How is useful if before working on something (that could be a stupid thing like running a script to rename a bunch of files) I have to first copy the files that I intend to work on in the WSL home, run what I have to turn, and copy them back? And what if I want my IDE in execution in Windows with the project in Windows and I want to launch on the project bash scripts? I hope they will not discontinue WSL1! If they will discontinue WSL1, unfortunately I will have to go back to cygwin that was not great but worked mostly fine, since I need integration between Windows and Linux.

robbyt 6y ago

Rushing half-finished products out, offering little/zero support is the new Microsoft. The reason $MSFT loves open source is because they can get press hype over projects that are 75% complete (which is the main goal), and they don't even need to support it, document it, or make it actually work.

lallysingh 6y ago
New? Windows 95 comes to mind.
- ConceptJunkie 6y ago
  DOS 3.0 comes to mind as well.
corty 6y ago
Half-finished releases haven been Microsofts SOP since forever. And especially for payware, bugs are only fixed in the next release, so you need to buy the subscription or the new release.
- mekoka 6y ago
  Really? https://github.com/microsoft/WSL/issues/4619 https://github.com/microsoft/WSL/issues/4619 https://github.com/microsoft/WSL/issues/6069 https://github.com/microsoft/WSL/issues/6069
  - corty 6y ago
    "haven" should be "have". Sorry, cannot edit it now.
uncledave 6y ago
Yeah I think you nailed it there actually. That's exactly their modus operandi. What's even worse is they have managed to abstract most of the support away in this cycle. You can't get enterprise support now because they gutted that entirely. You can't get them to do anything on github because they keep moving all the projects around and erasing them all or auto closing the tickets and no one on first line support knows anything now other than how to reset a Microsoft account password.

tarr11 6y ago

Huh, I had the opposite experience trying to use wsl1 with a rails app, which required lots of workarounds. Postgres never worked for example natively. Several npm modules would fail when running webpack. wsl2 worked perfectly for these cases. I wonder if people are mounting an ntfs volume in wsl2 which is really slow and janky?

tyingq 6y ago
There's examples of people using the Linux filesystem and having the issue. From reading the issue and related ones, it sounds like it might be related to some sort of unpredictable unclean VM shutdown.
cambalache 6y ago
I develop Rails in WSL1 just fine. > Postgres never worked for example natively. That's a minor incovenience at worst. I will stay put in WSL1. If I wished a VM I would have just installed VMWare and run some Linux ISO image from it.
- pydry 6y ago
  I mean, why not do that? I tried WSL because I thought it would be faster than a heavyweight VM. Turned out it's dog slow in comparison. Honestly don't see a use for it.
  - shawnz 6y ago
    I find the opposite, WSL1 is much faster for pretty much every usage except workloads that involve reading/writing lots of files.
    - pydry 6y ago
      The difference on I/O is enough to make WSL unusable. I wasted a day trying to figure out if I had a problem with anti-virus or something that was blocking me before realizing that WSL I/O is just... well, slow. People kept telling me to upgrade to WSL2 to solve that but the version of windows I had didn't allow it. Might have been a blessing in disguise given the data corruption bugs.

snarfy 6y ago

I was using WSL to do esp8266 development so I could use linux tools. The official esp8266 windows toolchain is based on cygwin. If I'm using something that needs a unix environment anyway, why use cygwin when you have WSL? I upgraded to WSL2 because well 2 is bigger than 1 so it must be better. But no, nothing worked. Serial ports are not supported in WSL2.

Scene_Cast2 6y ago
I literally spent the last couple of days getting ESP32 to work under WSL. Was not painless. You can have WSL1 and WSL2 side by side IIRC. And there are scripts out there to pipe serial into WSL2.
sz4kerto 6y ago
http://matevarga.github.io/esp32/m5stack/esp-idf/wsl2/2020/05/31/flashing-esp32-under-wsl2.html http://matevarga.github.io/esp32/m5stack/esp-idf/wsl2/2020/0... Here's how you can flash ESP devices under WSL2.
yjftsjthsd-h 6y ago
> why use cygwin when you have WSL? Well. Has cygwin ever corrupted get repos?
- shawnz 6y ago
  No, but WSL1 (which they are referring to in that quote) also has never done that.
Koshkin 6y ago
Why use WSL if you have Cygwin?

hvdijk 6y ago

I don't think calling it WSL2 was a mistake. It wasn't something that was good for the users, but it had a very clear benefit for the people working on WSL: calling it WSL2 allowed them to close WSL1 issues en masse as "fixed in WSL2" and never look at them again.

zamadatix 6y ago
You can say "fixed in <name>" regardless if the name is numerically sequential.
- hvdijk 6y ago
  True, but if MS hadn't presented WSL2 as a variant of WSL, any issues fixed in WSL2 wouldn't count as fixed in the WSL issue tracker. I would prefer it if their issue tracker marked these, more honestly in my opinion, as "This issue is will not be fixed in WSL, you can migrate to HVL instead" (using HVL as a hypothetical name for WSL2) with a separate HVL issue tracker.
  - andrew_ 6y ago
    A poor argument IMHO. A naming change for the sake of an issue tracker that appears to be a net negative for users is not a wise choice. Naming and branding doesn't exist to serve the project's management tools.
  - zamadatix 6y ago
    Whether they are counted as fixed in the WSL tracker is completely up to them. "Fixed, use HVL" is just as valid way to close a WSL1 issue ticket as "Fixed, use WSL2".
  - tw04 6y ago
    I guess I don't follow your point. The very reason WSL2 exists is because there were countless issues that COULDN'T be fixed with the way WSL1 was implemented. Why would they leave an issue open they fixed, just because the fix required a complete re-implementation? Furthermore why would they change the name, this is literally how they are carrying forward the functionality of WSL 1. It's still Linux on Windows, there is still a custom subsystem to allow the functionality. It is quite literally still Windows Subsystem for Linux. As documented: https://i.redd.it/po98dksksjx21.png https://i.redd.it/po98dksksjx21.png Should Mac Office not be called Office because they completely re-wrote it?

lukeschlather 6y ago

Cygwin was fast and mostly just worked. I did not find WSL to work well, WSL2 seems more usable. Still has warts but definitely an improvement.

deleted 6y ago
[deleted]

sys_64738 6y ago

If you drop WSL then you get confused branding of what they are. WSL1 and WSL2 make it pretty clear you're getting the Hyper-V thing for the latter and the former is a Linux sys call API layer. I'm actually surprised they can't be used together.

javajosh 6y ago
Those names don't imply anything about their implementation.
- hunter2_ 6y ago
  Tangent: they imply running on Linux; a Wine substitute.
archsurface 6y ago
Agreed. Whatever the implementation the name indicates the next step in this solution. To do otherwise would be like naming windows95 something other than windows after windows3.1. Marketing.
freeone3000 6y ago
There's a few exclusive portions, like the executable load error handler that triggers ELF to load under the subsystem, and the binding of the 'bash' executable. But mostly, to prevent a great deal of confusion.

ConceptJunkie 6y ago

> and certainly better than hoary old cygwin. Say what you want about cygwin, but it never did this.

uranusjr 6y ago
Parent was talking about WSL1, which didn’t do this either.

throwaway201103 6y ago

The last job I had where I had a Windows desktop (about a decade ago, now) I used Cygwin extensively and never had any big issues. That includes running X11 not just shell stuff. It was quite solid.

deleted 6y ago

[deleted]

ihaveajob 6y ago

Docker support was the main reason to upgrade in my case. IIRC, WSL was missing some key functionality that made Docker unusable for my purposes. Of course I don't remember the details; all I know is I had no real choice.