Hacker News Reader

Comment by stevenwliao | Hacker News Reader

> The first version of WSL is marred with terrible file-system performance...

Does anyone know why this is and how it can be fixed? (Either by the Windows team or by end users)

I know the rough high-level, and it's not necessarily WSL. POSIX programming does stuff differently than NT programming, the main or at least most noticeable design pattern being frequent process creation and lots of small IPC calls. On Windows this is slow. POSIX programmers also tend to set up directory structures with many small files. This is not necessarily slow on NTFS, but Windows' implementation seems to have many pathological edge cases.

There is also of course some translation overhead. That may be in the driver filter stack, though that is decently designed (it's close to having filter code pass over zero-copy state).

As I recall, WSL1 uses NT's built-in personalities functionality to provide a Linux-compatible environment, but it still used NTFS which is much slower in the lots-of-small-files use case.

The perception I had was that it wasn't just the lots-of-small-files use case, but the worst case combination of the impedance mismatch in NTFS versus Posix-expected (and thus emulated on top of NTFS) file ACLs, locking strategies, and cache flushing.

Using Git for Windows directly versus git inside a WSL space has night and day performance differences, but the number of small files is consistent between the two.

can WSL mount a volume ( like a xfs formatted file ) ? which could offset the ntfs performance issue ?

People I know have given up on NTFS, and use Linux file systems served to Windows (WSW?) via SMB for anything not read-only. Amazingly, that's faster than native, at least for their uses.

Ultimately, to bring Windows into the 21st century, Windows will need to be transformed to a gossamer-thin Wine-like wrapper stretched over a sturdy non-Microsoft frame.

Reply on news.ycombinator.com