Hacker News Reader

Comment by omcnoe | Hacker News Reader

/mnt/c is a mounted C: drive in WSL2, that allows WSL2 guests to read/write files on the Windows host.

The mount is fine and speedy enough, but the underlying reads/writes turn into native NTFS reads/writes through Windows. NTFS file API is incredibly slow - high fixed overhead for initial file access.

So patterns like node_modules with many small individual files (or compiling code in general) are much much slower on Windows or WSL2 /mnt/c due to the fixed overhead adding up over a large number of files.

It's a ridiculous problem that has plagued Windows for years.

View on HN

It's the file system filters that are an issue on Windows. It trades performance for extensibility.

NTFS itself is a fast file system.

"NTFS itself is a fast file system"

File access is significantly slower on Windows compared to Linux on the same hardware. You can run Linux inside a VM and it will easily beat the host OS in filesystem performance.

If the problem is not NTFS, then it is in how the Windows OS uses it

> If the problem is not NTFS, then it is in how the Windows OS uses it

Isn't that exactly what the comment you are replying to is saying?

This is correct. The flexibility of the file system filter model does have a performance penalty and you will see that across file systems.

This is why 'DevDrive' exists for ReFS, to reduce that penalty (though ReFS comes with it's own, namely in write performance due to journaling).

The model wasn't a big deal back in the day of IDE and SCSI, but it certainly shows on flash storage.

This is what I keep hearing. However, I have never had the good fortune of using a Windows installation where NTFS was allowed to be fast.

eBPF has opened the door to such bloatware on Linux. Previously there was no easy, stable way for enterprise bloatware vendors to maintain complex file and subsystem filter and analytic modules. Now that market is exploding because of eBPF, and it's a big reason there's so much work around growing eBPF's capabilities.

Could you expand? I never understood why this was considered acceptable, how is windows filesystem so slow compared to linux?

I am familiar with the issue, doing any sort of ruby development is a nightmare on windows because each require loads a file becoming increasingly slow at boot time

WSL2 operates through a file-level translation layer, not unlike NFS in Linux, which can be a huge performance problem for programs that manipulate lots of tiny files, like git or npm.

Programs that manipulate lots of tiny files are a performance nightmare on Windows even leaving aside the issue of WSL2.

git and npm install are somewhat slower on vanilla Windows, true, but on WSL2 they're downright unusable

Reply on news.ycombinator.com