Hacker News Reader

Comment by dataflow | Hacker News Reader

AFAIK that's an incorrect meme that just won't die. The performance issues you're thinking of have nothing to do with the filesystem itself, but with the I/O subsystem in Windows more generally. If you have evidence otherwise please share.

View on HN

Microsoft itself admits there are performance issues with NTFS, which is one reason they created ReFS.

For example ReFS removed the MFT which caused various problems.

I'm on my phone and this is a longer discussion than I can have here, but the performance problems they're thinking of and the ones people usually rant about on these forums are not the same ones (or same magnitude). Before being so confident it's NTFS itself that's the issue, try ReFS (and FAT32 for that matter) and tell me if you see the performance problems you've encountered actually improve a lot. And then narrow down the cause. You might be surprised how much of it had to do e.g. with filter drivers or other things. And don't forget you're still testing one particular implementation on one OS, which doesn't say anything about a different one for the same filesystem on a different OS.

I have been running ReFS for many years now on all but the system partition. But for reliability/self-heal reasons.

The MFT was annoying because if you create 1 mil files, and the delete them, the MFT will not be shrunk back.

> I have been running ReFS for many years now on all but the system partition. But for reliability/self-heal reasons.

Have you ever benchmarked it against NTFS? With the same exact set of FS filter drivers running on both? How much does the performance differ?

There are tools like voidtools Everything2 and WizTree that directly read NTFS from disk device bypassing windows FS apis and are blazingly fast (faster than find/du on ext4 in Linux).

'Everything' is caching all the files in memory and indexing them. Completely different than find/du on Linux.

Reply on news.ycombinator.com