Recently, someone asked me why, exactly, I didn’t think much of NTFS. I couldn’t come up with anything much specific more than “It’s old! and sucks!” so I decided to go and deliberately read about NTFS.
Now, you can’t trust marketing material on file systems, but I was nonetheless amazed to read a slide describing automatic incremental online file system check in NTFS (slide 18 in this slide deck). “Wow,” I thought, “Maybe NTFS is actually way ahead of everything else in file systems and I’m just another narrow-minded UNIX developer.” Then I flipped to the next slide, which described the fabulous new innovation of “symbolic links.” Whichever the truth is – NTFS is wildly advanced or terribly backward – we are clearly living in parallel file system development worlds.
I’m not the expert on NTFS, but I thought I’d summarize what I learned in an hour of half-hearted skimming. My conclusion is that NTFS is a thoroughly modern file system in many ways but oddly crippled in others. At the buzzword level, NTFS uses B+ trees and extents in places, has metadata journalling, supports encryption and compression, and stores small files inline with metadata. On the other hand, the majority of file system metadata is still stored in one big chunk at the beginning of the partition (no block/cylinder/allocation groups to spread the metadata around the file system and get it closer to file data). NTFS does support sparse files now, but from what I understand the application must deliberately specify that certain ranges of the file should not be allocated. Symlinks are a wild crazy new feature limited to privileged users only, while directory hard links are permitted. I tried to find another reference to “chkdsk on the fly” but failed; I’m going to assume that’s typical marketing hyperbole until I find a more reliable reference.
I’d summarize my overall impression of NTFS as all the latest coolest bits and pieces shoehorned into an ancient on-disk format (more ancient than usual) and never given a good high-level optimization pass. Real-world performance work bears this out; NTFS quickly fragments under load.
NB: 2.6 includes an in-kernel NTFS driver, which has had limited write support for quite some time now. I find that a lot of people (including me) assume that NTFS access was still only through a limited read-only out-of-kernel driver or through FUSE.