Hacker News Reader

Comment by creata | Hacker News Reader

> Linux and Win32 filesystem APIs were too different, and translating them made some apps and some workflows seriously suffer.

Is the reverse also true? Does Wine face any similar performance problems?

View on HN

I guess the main issue is, that Windows filesystem APIs are slow. Windows does a lot of things when opening/closing file handles (acls, virus scanning, and many more). Unix style applications with a lot of small files just perform really poorly. That's also why npm install takes ages on Windows.

They made it much better with Dev Drives, that use ReFS instead of NTFS and disables most of the filters in the filesystem stack.

The file operations on macOS are rather slow too. I needed to invest in some rsync-based syncing for an in-docker application build as accessing the mounted volume from a Docker container was around 20 times slower than on Linux :O

That’s another issue. The access from macOS/windows to the Linux filesystem (docker volume) is over the loopback network. Also the other way around docker bind mounts to windows/macos filesystem.

Every FS I've ever had the misfortune of using chokes on lots of small files, especially if they're stored in a flat manner.

Everything except FAT/NTFS is fine for small files. Refs works fine on windows too.

Listing large directories is slow. But it is what it is.

I am advising a dev team that's used to using windows to use WSL for the new NextJS app we're building.

But the filesystem performance really put a huge spoke in this. I thought everything was better with WSL2, but I was surprised to see that MS hasn't engineered some driver or something that would make this much more performant or pass-thru so that you can have a directory on windows but also have it perform really well in the VM.

No, don’t use WSL for JavaScript development. Dev Drive is what you’re looking for.

But also pnpm has quite decent performance on NTFS, it uses symlinks

Sadly DevDrive doesn't perform that much better. ReFS write performance is slower than NTFS due to journaling.

https://github.com/NullVoxPopuli/disk-perf-git-and-pnpm

WSL2 is fine for JavaScript development. Just don't put the npm files on a Windows host filesystem. Put them in the Linux filesystem.

Only if you don't use windows tooling. If you use a native windows git client over the network file share, trouble begins. Even vscode without remote wsl core.

You can put everything inside Linux, but then it's better to switch to Linux completely. Doesn't make sense to do everything inside the wsl vm.

Node/js development works really well on native windows. Some things are a bit slower, but it's not horrible.

Put it inside the VM disk instead of the host filesystem and access that from the host instead when you need to exchange data.

Yeah we ended up doing that, thanks. And it took a good 2 hours of fiddling to be able to access the files in windows.

Umm you must be rather inexperienced in Windows and didn't do much search for that to happen.

1. WSL2 mounts Windows drives under /mnt/ . You can just cp things

2. WSL2 Distros are exposed as Network shares. WSL installs a virtual "Linux" shell folder to Desktop and explorer navigation bar. It is hard to miss. Moreover a simple search query would show you \\wsl$ share

This was the top result for me:

https://askubuntu.com/questions/1439131/access-root-user-dir...

I will start by saying I haven't used Windows as my full time desktop in 20 years. I did use VS/Windows for 2 years while I did a C# project in 2013-2014, managed a bunch of windows servers, used (and liked) powershell, everything, but that was inside a VM on my mac. And the other two windows full-time devs I was helping had never used linux or WSL (and one of them was not terribly keen on the whole idea). But we were all new to WSL. I knew WSL was very easy, and even many devs at MS use it.

So to provide more detail, things were slowed down further because this was one of those teams meetings where you can't just take over, but have to tell someone to type another command and wait for them to type it. The second thing was that the user didn't tell me that they were switching to another user when escalating to admin (cuz I couldn't see that elevated system dialog in the screen share). So it turned out they had installed WSL as a different admin user, so when they went to \\WSL$ (as their original user), it wasn't showing any shares. That set off a lot of googling and claude'ing that went nowhere.

Suffice to say I was ready to end the day after that meeting :-)

A red flag early on was when a bun install took 8 mins when trying to run it on /mnt/c, when it took 200ms on my machine. So I knew there had to be some weird filesystem overhead stuff going on. So then when we got it working beautifully by just using the VM's filesystem, I was personally happy with it but the person on the other end felt this was all too cumbersome and was soured on WSL, even though I tried to explain the differences.

I kept thinking that WSL was the greatest thing since sliced bread and got the message that MS had found a way to make them work beautifully together (especially in WSL2). I'm sure I could've figured this all out on my machine in probably 10 mins.

I never felt the need, and if using Turbopack, even less.

Actually, there's an interesting question - how does Wine implement (or not implement) Windows API calls which interact with filesystem features which aren't available on Linux, like alternate data streams or complex ACLs?

From a quick search, it sounds like ACL metadata is stored in a way that's specific to NTFS. Given that Wine prefixes don't tend to have their own partitions, I'm guessing that if Wine supports them, they just store the info in a config file (similar to how the registry is implemented via text files stored in the root of the prefix) and then looks up accesses from there.

Wine probably isn't something you'd want to use if you're concerned about actually enforcing full Windows security rules. Even if you were able to enforce access to files when executing within Wine itself, the wine prefix will still usually just be a bunch of 644-permissioned files sitting on a Linux filesystem that can get used like any other; the entire wine prefix is just a regular directory with regular files from the external perspective of the wider system, and nothing stops anyone from doing whatever they want that they could do to any other file with the same permissions.

wine gets support from the kernel, like case-insensitive directories on ext4.

Reply on news.ycombinator.com