6 ms·
Have to agree on all points. You’ll find the slow file operations are entirely down to NTFS. Regardless of how you play around in fsutil it’s hopeless on lots
by setquk 8y ago
Have to agree on all points.
You’ll find the slow file operations are entirely down to NTFS. Regardless of how you play around in fsutil it’s hopeless on lots of small files. This incidentally makes WSL unbearably slow. Hence why I still use VirtualBox and putty.
- m_mueller 8y agoI was suspecting as much. I wonder why NTFS gets so much praise, especially compared to HFS+. Yes, HFS has less features, but at least it lets me get my work done.
- setquk 8y agoNTFS deserves no praise. None at all. Not sure I've ever heard any to be honest. edit: fine example as I got a downvote. SVN checkout on windows NTFS 8 minutes 30 seconds SVN checkout on same kit on ext4 48 seconds. This problem scales to git as well, so is not SVN related. Anything that does lots of small writes, so basically anything unixy, suffers like this.
- nahalz 8y ago^ This is true. Dealing with lots of small files is SUPER SLOW in NTFS for some reason.
- barrkel 8y agoNTFS was much better than FAT, and was one of the first journaled filesystems in widespread use. It was praised perhaps 20 years ago.
- m_mueller 8y agoI've read/heard a couple times from people ridiculing Apple's HFS pointing out all the ways in which NTFS is superior, so in my mind at least the filesystem I never thought of as an advantage on macOS. I guess I was wrong then.
- barrkel 8y agoI think it depends on your metric. I don't know what's wrong with HFS, but I do know that Apple drops these .DS_Store entries all over the place, things that look ideal to be stuffed in NTFS streams. I'm sure there are many metrics on which HFS is superior to NTFS; and probably many metrics where NTFS is superior. NT (and MS in general) has never philosophically worked well with more than N of X, wherever N is significantly larger than a consumer would deal with - whether it's processes, files, TCP connections, whatever. Their consumer heritage usually finds a way to shine through.
- deleted 8y ago[deleted]
- passwd 8y agoNever checked if it was NTFS issue, but it felt like logical explanation - when starting Stronghold Crusader through wine on Linux, loading took like 0.5s, compared to 10s or so on Windows. Didn't bother to check the numbers, but it was order of magnitude for sure. Way more than just noticeable.
- ygra 8y ago> Anything that does lots of small writes, so basically anything unixy, suffers like this. To be honest, when NTFS was conceived it probably didn't have as a design goal that common Unix patterns should be fast. After all, Unix applications use the file system for lots of things where Windows has different mechanisms for that purpose. SVN sadly has to traverse the complete working copy and lock every single directory individually because every directory is also a working copy on its own. Most of the time SVN spends on, e.g., update, is spent on locking and unlocking. Git/hg only need to do this in one place and avoid that problem.
- Dylan16807 8y agoIt's definitely not 'entirely'. I have a folder with a bunch of small files where explorer and other programs sometimes hitch for tens of minutes, and WSL can reliably process in seconds. It's too many seconds compared to native linux, but it's still seconds.
- jki275 8y agoIt's not NTFS -- it's Windows Defender's Realtime protection.
- setquk 8y agoIf you turn it off it still runs like ass. I have spent hours on this one even down to fsutil tuning and I can't get more than about a 10% improvement. This is because the small files are stored on the MFT which is global read/write locked.