Windows 10: NTFS vs ExFAT for a non-system SSD

Hello.

I have a SSD just for gaming. That is. A standalone partition without boot (only data; Steam and other games are stored there).

I am wondering if I would gain any benefit from going from NTFS to ExFAT.

Your opinions are welcome.

:)

 

Correct Format for USB Stick | FAT32? | NTFS? | Some Other Format?

So, that appears to indicate that Macrium doesn't care about the format... as long as the file system can be "seen" by your system.

I'd suggest exFAT...
http://www.pcworld.com/article/3109559/hardware/why-your-usb-drives-file-format-matters-fat32-vs-exfat-vs-ntfs.html

 

Can I move Windows 10 Hyper-V Instance to exFAT External SSD from Windows 8.1 Pro NTFS

I formatted the SSD to NTFS. I wish I could use the new exFAT format, which is suggested to be better for SSD.

 

[TL;DR use NTFS]

You will not gain any benefit. Accessing the disk will be several orders of magnitude slower as total amount of files increase.

ExFAT is good for small partitions that don't carry any important data, it is just as fragile as FAT32 and other non-journaling filesystems.
FAT32 Is good for compatibility with almost any device, which usually outweighs it's fragility.

NTFS will be faster, will support TRIM (critical for SSDs), there is better filesystem caching, there is metadata to make some filesystem accesses instant. Most importantly though, NTFS is a journaling filesystem. That means, in simplest terms, that every operation is first recorded to the journal before it is actually carried on the data section of the disk. If there is sudden powerless, BSoD, or other unexpected mishap, even if the system was writing data to the filesystem, you have a very high chance of recovering most if not all of the data.

The FAT family of filesystems are extremely simple in operation. This sound good at first, especially for SSDs, but once you look into it further you can see it's folly. Basically FAT filesystems have 2 parts to them. An index, and a big pile of clusters. Kind of like a big ass book with a nice table of contents which is easy to read, but then followed by eleven thousand pages of size-1 font print with no pictures. To access each and every file, the system has to look through the index, one-by-one until it finds what it wants. Then it's gotta zoom to that cluster and hope that the data it expects I actually there. If it isn't, to bad so sad, files gone forever.

Games will suffer even more. Especially steam games which make frequent accesses to game data stored in archives and databases.

Leave FAT and friends for the floppy disks and digital cameras. Just about any other device can and should use a filesystem that doesn't suck. To bad Windows doesn't have a btrfs driver.

 

ExFAT was designed for external drives where it has some advantages over NTFS. For internal drives it has nothing to offer but does have some serious limitations, such as no security. Normally you won't even be given the option of using ExFAT on internal drives.

 

Internal and External makes absolutely no difference. You can write a filesystem to any device that has standard sectors.

A hard disk inside your computer, attached to SATA, is the same exact disk outside your computer connected via USB/eSATA/1934 or whatever interface. The same goes for filesystems. ExFAT is still ExFAT whether its on a 32 Disk RAID-0 SCSI array or is on an in memory emulated SDCard connected to an android virtual machine running on a wrist-watch.

 

Thank you very much for your thorough explanations gentlemen.

 

First, stop spreading FUD about ExFAT:
- TRIM works just as fine on it.
- NTFS will never outperform FAT in troughput, since security and journaling are OVERHEAD.
- Ex-FAT was actually built to minimize writes in order to prolong life of SSDs. No journaling and less precision for timestamps also helps there.
- Preemptively striking the search aspect, ExFAT does have great optimizations (hashing) for locating files.
- The biggest disadvantage of FAT was increased fragmentation - guess how that applies to SSDs.
- ExFAT is nothing like the old versions when it comes to reliability. It has multiple checksums in place, built with speed in mind
- Data loss at sudden power loss might still be an issue with mechanical drives, but we are talking here about SSDs.
- All of these have zero relevance to a game, as most don't use native methods to access their compact, well organized files, don't need to search for arbitrary files since it should know it's own files in advance, and lastly (just because I don't want to go further), verifying access rights will impede speed.

I only have a lame mlc, and still Steam and Dota 2 seems to update faster - might be just placebo, but it's definitely not slower.
And that's how it's supposed to be - not having all that overhead it's theoretically great (eh, just small speed bumps) for games on ssd. The only disadvantage is wasting more space to store small-size files - and those are rarely used by games.

I use ExFAT on all my storage partitions, no matter if it's hdd/ssd/microsd/usb. Getting early support in Android helped a lot. In fact, I would have never used NTFS outside system drive if it were not for the 4GB file limitation.

 

Hi there
Most games AFAIK (I'm not a gamer so I could be posting B/S here) don't rely on an excessive amount of actual DISK I/O - but just loading up data for the game to start.

So it seems almost a WASTE to store Game data on an SSD.

SSD's are best for running the OS, perhaps scratch files for things like Photoshop / Video editing where you need considerable Disk I/O and for paging files.

User data which doesn't change significantly is best left on "Spinners". For example multi-media files would be totally wasted on SSD's.

As far as "Consumer grade" computers and HDD's are concerned none of these file systems will really make a significant difference - any performance "improvements" will be negligible compared to the actual performance of the HDD's themselves (for example HDD's --5400 RPM / 7200 RPM / 10,000 RPM and the size of cache). If you have the slower 5400 RPM HDD's probably with a smaller cache your overall system performance will be just HORRIBLE however you cut it - even with an i7 processor.

It's amazing that people still fail to realize that on modern machines it's usually the HDD's themselves that are the biggest bottleneck - however much RAM and whatever the power of the CPU. The type of file system isn't normally a significant factor unless you want more "resilience" then other factors such as RAID can come into play.

Cheers
jimbo

 

I can tell you are not a gamer otherwise you should have known about Dota 2 that I specifically talked about *Smile
That's unlike any other game in terms of stress put upon drives. It's like a freaking torrent app. Poor data organization, countless humongous updates, complete lack of respect for caching (did you just alt-tab? enjoy 30mb of refreshed ads). God forbids your game is unstable and you crash often, all while your team awaits you to reconnect for a competition. Or you get unlucky and have to reinstall the whole thing - 2 times in a day. That's why I get people trying to squeeze even the smallest % increase in performance and I won't mock them.

 

I'm not. You however declare that filesystems are more robust on SSDs than HDDs. The medium doesn't matter, when a non-journaling filesystem, especially one as primitive as ExFAT , is left with invalid data structures. That data that wasn't written is permanently lost. There's no way to flush write caches that no longer exist.

Not on every operating system. UNIX operating systems cannot properly handle TRIM with ExFAT. Open source NTFS drivers can however. If you ever dual boot Linux, or perhaps use a mac with bootcamp, you shouldn't use ExFAT on an SSD.

Filesystem security data is cached in RAM. There's no overhead in disk IO when it comes to security. Security is a pretty nice feature to have as well.

Journaling is only overhead during writes, even still, on an SSD, the journal gets written so fast that any overhead is outweighed by many orders of magnitude by what it provides.

SSD write cycles killing drives is pure useless FUD. Modern bargain SSDs can withstand thousands of times their capacity in data written without any sign of pre-failure. If the overhead introduced by NTFS or any journaling filesystem is calculated, that would take several hundreds years of non stop journal IO.

b-tree will ALWAYS be faster than looking up files via brute force. Even with filename hashing, you still have to compare the hashes by brute force. Which is dumb.

That and filesystem corruption (remember how your heart sank when Windows crashed prior to XP+NTFS?)
Seeing as this was only a problem over a decade ago, I'm surprised you'd even bring it up. Only an idiot would use a FAT-family filesystem on a mechanical drive by choice. The only reason FAT is still around is for compatability and royalty-free implementation. ExFAT can't even claim either of those.

Yes it is. Checksum only make it easier to prove data is in fact corrupt. It doesn't protect your data or offer any reliability. A checksum is a lossy (one-way) representation of data. You can't recover any of the original data from a checksum...

ExFAT is a worthless extension to an ancient filesystem.

...

Its impractical for a game to find its files, no matter how well organized their internal structure may be, without using the filesystem. Otherwise they would have to know the exact offset of the disk where the file begins, the total length of the file, and whether it was virtually fragmented or not. If the file was in fact fragmented, they'd have to know each offset and length of each fragment. SSDs are NOT immune to fragmentation, they just don't suffer the performance hit. The exact same problems apply that did for HDDs when you do low-level access to the physical disk. In fact, the problems are magnified on SSDs because there is no defragmentation of the data.

(SSD's present data sector by sector just like HDDs. The physical layout of data on the NAND is not accessible or visble and is controlled entirely by the drive's controller, and is typically a somewhat closely guarded secret.)

Security is good, verifying access rights is not done for every file operation, only for the initial access to API call. You can call CreateFile() with ALL_ACCESS, and security will be checked once. All further writes to that object will happen under the security context of ALL_ACCESS. Overhead is minimal unless you write a program which calls CreateFile(), ReadFile()/WriteFile(), CloseHandle(), for each and every read/write, which is stupid, and more work than doing it correctly. Even still, the overhead of doing that is still small on modern hardware.

NTFS will outperform ExFAT for updating your games (although networking unpredictability is probably why you saw any advantage with ExFAT).

With NTFS filesystem caching is better, finding files is faster, writing files is faster. The only thing ExFAT might be better at (other than corrupting your data) is large sequential writes when there is a lot of free space available.

Wasting more space to store small sized files? You mean files below the cluster size? Cluster size ideally should be set to the erase-block size of the NAND (my opinion). Otherwise you'll actually introduce A LOT of overhead. The filesystem is irrelevant when it comes to erase-block and cluster sizes though.

I wouldn't recommend that, but do as you please, just so long as you don't claim what I say is spreading FUD.

 

Hmm. I think both of you have valid points. Otherwise I don't understand why MS invented ExFAT (maybe useful for thumbdrives though).

 

There's a lot of things nobody knows why Microsoft invents.

Take the Windows 8 Start Screen for instance.

 

Seriously all this in this thread is a moot point if the drive isn't being accessed by non-Windows OS. If it is go ex-fat if its Windows only go NTFS. Its as simple as that.

 

In fact it's not even a good idea to use ex-fat for access with non Windows operating systems. Compatibility isn't always guaranteed. And If the non Windows os is Linux one is definitely better off using NTFS which works perfectly with Linux instead of ex-fat. Seriously, I don't know why I should ever format any of my external drives with ex-fat. If compatibility is an issue I go for fat32, otherwise it's either NTFS or in the Linux world it would be ext4.