4 ms·

> 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 W

by creata 10mo ago

> 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?

andix 10mo ago
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.
- Gabrys1 10mo ago
  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
  - andix 10mo ago
    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.
- perching_aix 10mo ago
  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.
  - andix 10mo ago
    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.
- atonse 10mo ago
  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.
  - andix 10mo ago
    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
    - p_ing 10mo ago
      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 https://github.com/NullVoxPopuli/disk-perf-git-and-pnpm
    - dboreham 10mo ago
      WSL2 is fine for JavaScript development. Just don't put the npm files on a Windows host filesystem. Put them in the Linux filesystem.
      - andix 10mo ago
        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.
  - the8472 10mo ago
    Put it inside the VM disk instead of the host filesystem and access that from the host instead when you need to exchange data.
duskwuff 10mo ago
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?
- saghm 10mo ago
  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.
the8472 10mo ago
wine gets support from the kernel, like case-insensitive directories on ext4.

by creata 10mo ago

andix 10mo ago

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.

Gabrys1 10mo ago
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
- andix 10mo ago
  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.
perching_aix 10mo ago
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.
- andix 10mo ago
  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.
atonse 10mo ago
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.
- andix 10mo ago
  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
  - p_ing 10mo ago
    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 https://github.com/NullVoxPopuli/disk-perf-git-and-pnpm
  - dboreham 10mo ago
    WSL2 is fine for JavaScript development. Just don't put the npm files on a Windows host filesystem. Put them in the Linux filesystem.
    - andix 10mo ago
      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.
- the8472 10mo ago
  Put it inside the VM disk instead of the host filesystem and access that from the host instead when you need to exchange data.

duskwuff 10mo ago

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?

saghm 10mo ago
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.

the8472 10mo ago

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