Hacker News Reader

Comment by behnamoh | Hacker News Reader

> Windows’ file I/O and process launching is so slow.

It's not Windows' fault, rather it's NTFS.

There's some documentation on this in some WSL issues on GitHub, but it's not just NTFS. It's stuff like the broader filesystem architecture's inclusion of pluggable 'filters' (kinda neat, but each layer of them incurs a performance cost) or the way commands on other operating systems depend on caches for certain syscalls that Windows doesn't keep, or keep anything equivalent to.

Too tired to go find them atm

This one? I remember it as an earnest description of the difficulties the WSL team had with the speed of NTFS - and I think it was one of the reasons for the switch to virtualisation in WSL2.

<https://github.com/Microsoft/WSL/issues/873#issuecomment-425...>

Yeah, that's the GitHub comment, thank you!

My takeaway from that comment is that there are some important performances issues that apply generally to all filesystems on Windows. Maybe we can partially test whether that's the case by playing with WSL1 on ReFS, ExFAT (if that's even supported, with its limited permissions support, or ZFS, once OpenZFS on Windows stabilizes a bit.

NTFS is Windows' fault.

https://m.youtube.com/watch?v=qbKGw8MQ0i8

Rather it's their baroque ACL permission system, which is not able to cache inherited perms.

The ACL permission system is in NTFS. For example FAT32 doesn't have it.

Yes, but if you turn off inheritance perf goes up 10x. It's a policy, not the NTFS driver itself.

Can you provide links providing more info for those statements?

no, just try it out.

all my cygwin build rules contained turning off inherited perms to be able to compile bigger systems under an hour. e g. https://github.com/rurban/cygwin-rurban/blob/master/release/...

Reply on news.ycombinator.com