Comment by muststopmyths | Hacker News Reader

Comment by muststopmyths | Hacker News Reader

Parent Full thread

I'm sure I'm missing something but I don't get this problem with filesystem access performance. It seems the obvious way to do this was to have SMB mounts on either side and optimize the hell out of the already existing SMB implementations on both OSes to get the performance close enough to disk. Maybe have a dedicated virtual network interface exposed only to the VMs and not to the LAN to avoid security issues.

It probably wouldn't get exactly up to native high-end SSD performance but I'd wager you can get it close enough that people wouldn't care.

Meanwhile, try to do a "git status" right now in Linux in WSL2 on a sizable repo in your /mnt/c and feel yourself slowly die inside.

It seems like a bunch of people thought it would be a great science project to write custom kernel drivers for Linux and Windows and learn some stuff along the way. So now they're stuck supporting two complicated software implementations for god knows how long, because neither of them does the job on its own.

Like I said, I'm probably missing something. I'm a network guy, so maybe to me everything can be solved by the network stack.

(edited last line)

Great question. They do have an in-depth blog post of how it works for WSL1: https://docs.microsoft.com/en-us/archive/blogs/wsl/wsl-file-...

Though it doesn't mention why they didn't try what you suggested.

The actual I/O doesn't seem so bad...like writing to a single file. It's things you mention, that create or modify lots of files (git clone, for example) that are really slow.

Edit: Apparently, the Windows side \\wsl$\ access does do what you're suggesting, sort of: https://devblogs.microsoft.com/commandline/a-deep-dive-into-...

It's using a 9P network file server, derived from plan9.

> It seems the obvious way to do this was to have SMB mounts on either side and optimize the hell out of the already existing SMB implementations on both OSes to get the performance close enough to disk.

That's basically what they're doing, only that it's not SMB but 9p protocol servers.

Here is a video where they discuss the WSL2 architecture. The link is time-stamped to go to an overview picture of the architecture.

https://www.youtube.com/watch?v=lwhMThePdIo&t=2435

SMB to/from a linux VM is pretty slow, I've spent time trying to optimize it. The performance hits bottlenecks in a few places including (if enabled) transport encryption. You'll have similar problems if you try to shuffle a few gigs across an ssh tunnel locally too (if you're sufficiently clever and willing to wield a compiler in anger, you can disable transport encryption entirely for a nice speed boost).

For reference I had a situation where I needed to pull/push 1-2gb blobs across the VM boundary on a regular basis, so it ended up mattering a lot - sub-1-minute times vs 5-10 minute copies.

I really don’t understand why they disable the NULL cipher. If I want to take the risk and transfer data cleartext over my LAN I don’t see why I need to custom compile ssh/scp to do so (and miss out on security updates since its no longer a tracked package).

I still want my auth credentials encrypted so no telnet and other older tools are not a replacement.

I'm not really using wsl in anger (work laptop runs Linux, with a win 10 vm in virtualbox for the occasional nearly windows program; mostly the odd proprietary vpn; Citrix and occasionally rdp - although remmina on Ubuntu 18.04 mostly works fine) - but I've toyed with the idea of testing smb/cifs and nfs both ways - to see if it isn't good enough for a git checkout the size of the Linux kernel (Ditto a build/compile of same - although I'd normally mount a ramdisk for that, if I really wanted to speed things along).

Both windows and Linux should be fine with home on cifs.

Reply on news.ycombinator.com