Comment by lc64
2 years ago
That's a very rigorously written article.
Let's also note the 4x speed increase on windows 10, once again underlining just how slow windows filesystem calls are, when compared to direct access, and other (kernel, filesystem) combinations.
maybe the malware detection program adds to the performance as well
NTFS is really horrible handling many small files. When compiling/watching node modules (easily 10-100k files), we've seen a 10x size difference internally (same hardware, just different OSes). At some point that meant a compile time difference of 10-30 sec vs 6-10 min. Not fun.
NTFS is perfectly fine at handling small files and performs on-par with other modern file systems.
The issue is Defender in sync mode/other AV/other file system filters.
DevDrive as noted by default uses an async scanning technique as well as ReFS. ReFS will suffer the exact same performance issues with Defender (or other AV/other file system filters) doing its thing when running in sync mode, which it does by default for ReFS-formatted drives in Windows Server.
https://news.ycombinator.com/item?id=26737521
> Except for CloseHandle(). These calls were often taking 1-10+ milliseconds to complete.
> While I didn't realize it at the time, the cause for this was/is Windows Defender. Windows Defender (and other anti-virus / scanning software) typically work on Windows by installing what's called a filesystem filter driver.
This doesn't take away from your point that _it is slow_, but the reasons are not due to the file system in use.
14 replies →
> NTFS is really horrible handling many small files.
To pile onto NTFS, it's performance is so notoriously bad that there are developer teams working on Windows projects that configure their build farm to do cross builds from Linux to Windows just to avoid the performance penalty.
30 replies →
That may be due to a combination of Malware detection + most unix programs not really written to take advantage of the features NTFS has to offer
This is a great talk on the topic https://youtu.be/qbKGw8MQ0i8?si=rh6WJ3DV0jDZLddn
1 reply →
Must be why windows 11 added that dev drive feature
2 replies →
It’s somewhat more complex than “NTFS is slow”. Here’s a good explanation: https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
I’ve benchmarked deleting files (around ~65,000 small node_modules sort of files) and it takes 40 seconds through Explorer, 20 seconds with rd, and roughly a second inside WSL2 (cloned to the VM’s ext4 virtual hard drive).
Why not use https://github.com/bobranten/Ext4Fsd ??
So we should put node_modules into SQLite database?
1 reply →
Their "windows dev drive" setup addresses this. I haven't tested it myself but I saw a couple of inexpertly executed tests showing significant performance gains. I honestly have no idea if my compile times are quicker.
You can get benches from the horses mouth.
https://devblogs.microsoft.com/visualstudio/devdrive/
But the primary improvement comes from async A/V, not the file system.
ReFS offers other improvements such as CoW and instant file initialization which can benefit developers. From this standpoint, it is the correct choice over NTFS.
https://devblogs.microsoft.com/engineering-at-microsoft/dev-...
With the right code, NTFS is not much slower than ext4, for example. Nearly 3% for tar.gz and more than 30% for a heavily multi-threaded use like Pack.
https://forum.lazarus.freepascal.org/index.php/topic,66281.m...
https://news.ycombinator.com/item?id=18783525 has previous discussion on why windows filesystem is slow
But is it faster than accessing the filesystem with io_uring as well? I feel like this article should be updated
io_uring/IOCP won't change how long it takes to access a file.
So what's exactly the performance benefits of using io_uring to access files?
1 reply →