Now you are making even less sense...
Would "user intervention" include writing and then re-writing a high volume of files/directories? Creating many sparse files, or many compressed files? Since any of those will make fragmentation more likely.
What about intensive write/erase operations? Since that is likely to push a SSD into performing block erase operations during the write cycle rather than at times when the system is "quiet".
Right away, I can think of a mechanism.
it's called NTFS (legacy) compression, the compression is done in-place in 16KB chunks, and when space is saved, the $MFT is altered to track the freed up space. If you compress a 60GB file on NTFS that is uncompressed, the compression operation produces a huge number of fragments. In fact, this is when the "write fail" occurs.
___XXXXX___XXXXX___XXXXX___XXXXX___XXXXX___ 62% compression space improvement Could be fixed by defrag... if defrag was allowed.
All of the phenomenon described, are related to the design of the NTFS file system, and the slowness of the NTFS stack. This is one reason that producing 12GB/sec PCIe5 NVMe modules is so silly. Say a device supports 10^6 IOP a second. The OS cannot sustain that rate. The stack might be good for 10^4 or 2*10^4.
The Windows 11 Insider-edition OS, is making the file system even slower. Which is... some kind of accomplishment. Try deleting some files, and it is quite quite slow. That's what I keep testing on it, hoping for a change.
Paul
Have something to add? Share your thoughts — no account required.
Ask the community — no account required