3 ms·
Too bad the article doesn't talk about performance vs NTFS. Any quick and dirty comparative benchmark would have been nice. But then again, If BTRFS had been sl
by speed_spread 4y ago
Too bad the article doesn't talk about performance vs NTFS. Any quick and dirty comparative benchmark would have been nice. But then again, If BTRFS had been slower than NTFS it could have been due to a suboptimal (re)implementation.
- rbanffy 4y agoI think nothing these days can perform worse than NTFS. I’ve been using Windows on my corporate issue laptop and anything that includes disk IO is a huge pain.
- kitsunesoba 4y agoSome amount of that might be coming from Windows Defender and similar, but yeah NTFS isn't exactly a speed demon.
- garaetjjte 4y agoNothing particularly wrong with NTFS, it's Windows filesystem architecture that is slow.
- solarkraft 4y agoI can't find it right now, but I believe there was a talk from a Rust maintainer a while ago about the Rust installation being way slower than it should be, which was almost entirely a rant on Windows file system performance.
- ygra 4y agoThat one perhaps? https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8 I don't recall it particularly ranty, though.
- solarkraft 4y agoThat's it, thank you! I chose the word because I remembered it being a bit rant-adjacent ("we're used to doing it this way, ... but windows does it that way"). But it's been a while since I watched it (not particularly attentively either, to be honest). That's just what stuck.
- overthrow 4y agoI'd love to see a benchmark of NTFS on Windows vs NTFS on Linux. Unfortunately ntfs-3g uses FUSE so right now it's not really a fair comparison.
- mappu 4y agoLinux has an upstream kernel driver for NTFS, you don't need fuse ntfs-3g any more (well, they have different quirks such as how UNIX permissions are emulated). The readwrite driver is new, but it always had an older readonly driver too, which would be fine for benchmarking. Back in 2011 Tuxera's proprietary Linux NTFS driver was maybe faster than ext as well: https://www.phoronix.com/news/OTU5Ng https://www.phoronix.com/news/OTU5Ng
- overthrow 4y agoThanks I wasn't aware of that, I stand corrected
- ntauthority 4y agoOn Windows, I can enumerate a directory that accidentally got millions of files perfectly fine without the system itself breaking and with results being returned incrementally. On Linux/ext4, it takes an eternity for an enumeration to even start returning results and the entire OS gets stuck on IO while doing so.
- rbanffy 4y agoTrue, but that's not a common enough use case to optimize for. I'd prefer Windows updates happened at the same speed Linux ones do.
- Rimintil 4y agoThis is due to file system filter [drivers], not the file system. NTFS is perfectly fine and performs well.
- dboreham 4y agoHmm. I thought the problem was that NTFS is not particularly fast at file creation. Generally not a problem, except for the folks who wrote the npm tooling which generates 10,000 files in the blink of an eye.
- Rimintil 4y agoYep, I feel (a little) bad for anyone doing node development on Windows (though I probably should feel bad that they're having to dev in JS). But this isn't an "NTFS problem" as you'll have this occur on any filesystem that supports file system filters, like antivirus.
- brucethemoose2 4y agoI benchmarked both with a cross platform program. btrfs is massively slower on windows, especially with random IO (but also with sequential). Its even more disparate with compression turned on both. I cant remember the linux results... not that it matters, as I avoid NTFS writes on linux like the plague, even with the new kernel driver. Just this year, I tried trusting it for a little while, and linux ntfs killed an entire backup HDD by corrupting the partition table :/. Mounting NTFS as read only is OK though.