It's the first thing I disable whenever I want to do some serious disk I/O.
Also Windows still uses NTFS which dates back to 2000. For compatibility reasons, fair enough. But surely NTFS wasn't designed with SSDs in mind, let alone NVMEs.
Of course, that doesn't make it comparable to ext4 or zfs or whatever, but I wouldn't expect it to be the worst bottleneck in the system.
For example I'm running Windows 11 Pro on this machine with a brand new NVME.
"fsutil.exe fsinfo ntfsinfo c:" tells me [0] I'm running NTFS v3.1 which was released 22 years ago [1].
...like adding support for more filesystems.
I'm curious about what (and when) other parts of the IO stack have been updated. Something has to have changed to add trim support: I'm guessing the scheduler.
Wikipedia provides some hints:
> Although subsequent versions of Windows added new file system-related features, they did not change NTFS itself. For example, Windows Vista implemented NTFS symbolic links, Transactional NTFS, partition shrinking, and self-healing.[21] NTFS symbolic links are a new feature in the file system; all the others are new operating system features that make use of NTFS features already in place.
If I had to guess, most of these new functionalities leverage NTFS metadata: https://ntfs.com/ntfs-system-files.htm
It would be nice if Windows Defender tone down their on-the-fly aggressive scanning for anything I/O related. For any I/O activity, it regularly consumes up to 30% of my CPU. Moving files to a different directory rev up Windows Defender even it scans the folder in the past.
I wish there is a granular control over Windows Defenders in a way that it would not be aggressive with every I/O activity. I would assume that Microsoft intentionally did this due to rise of randomware attacks and we unfortunately have inept people who mindlessly clicking anything. And they don't want to be liable for being lax.
a different workload than browsing files in explorer?
oh wait maybe this isn't a joke? https://en.wikipedia.org/wiki/Transactional_NTFS