Is ExFAT slower than NTFS?



  • I'm contemplating moving my storage disks to ExFAT, to better facilitate using them from both Windows and Mac.

    So I formatted a fresh drive to ExFAT and copied files from one of my old partitions over. Then I noticed something strange. ExFAT seems to be noticeably slower than NTFS at just stating the file and directory metadata. Look at the screenshot below.

    Both property sheets were opened at roughly the same time. NTFS drive (left) has already finished counting the files, while ExFAT drive (right) is only 1/3 of the way in.

    This is repeatable every time I try it, on different directories. I did a quick copy test, but while speeds were all over the place, there was no indication NTFS is many times faster than ExFAT. The disparity seems to be limited to random disk access.

    Both drives are the same model, plugged in the same motherboard. Both are GPT, cluster size 4kb. NTFS drive has an extra partition that plays no role here.

    Before I dig any further, a sanity check please. Am I missing something? Is there anything wrong here at all, or is this expected with ExFAT?


  • Impossible Mission Players - A

    @cartman82 said:

    Am I missing something?

    Disk caching? Windows will keep stuff in memory (including, presumably, file tables) and if you've recently scanned the tree, subsequent accesses should be faster.

    I'm sure there are filesystem benchmarking wares you could use to test.



  • @Tsaukpaetra said:

    Disk caching? Windows will keep stuff in memory (including, presumably, file tables) and if you've recently scanned the tree, subsequent accesses should be faster.

    I'm sure there are filesystem benchmarking wares you could use to test.

    Repeated tests yield the same results.

    I'm not sure what would a benchmark show me. When the difference is x2 - x3, I can see it with my own eyes.


  • sockdevs

    ExFAT will look slower than NTFS because NTFS assumes it's on a permanent disc and so can take its time to actually write data blocks because you won't pull the plug on it. ExFAT makes the opposite assumption.

    IIRC there's a setting that tells an NTFS volume it's a removable one so windows will stop writecaching the volume, but bugger if i can remember where that setting is......



  • Why write caching should affect reading directory meta data?

    My guess is Microsoft has optimized for NTFS access but not for ExFAT (inset intentional MS conspiracy here).


  • Impossible Mission Players - A

    @cartman82 said:

    Repeated tests yield the same results.

    Interesting.

    @cartman82 said:

    I'm not sure what would a benchmark show me. When the difference is x2 - x3, I can see it with my own eyes.

    Well, some people have apparently done some benchmarks already.

    For the most part, it seems merely reading/writing files is roughly the same (or slightly worse with exFAT).

    Unless you're doing pretty intensive deadline I/O, I don't think it will matter too much in real usage scenarios. After all, how often are you counting all the file on the disk?

    Better test would have been to see how long it takes to copy files around (a la regular usage).



  • I've experienced problems under Windows with directories with a large number of entries. That slowed down the file system to no end. Can't remember which fs, though. Do you perhaps have very large directories?


  • area_pol

    Since you experience a significant difference on scanning the metadata but not on file read/write, it may be due to the different ways of storing/accessing metadata on those filesystems.



  • @accalia said:

    ExFAT will look slower than NTFS because NTFS assumes it's on a permanent disc and so can take its time to actually write data blocks because you won't pull the plug on it. ExFAT makes the opposite assumption.

    IIRC there's a setting that tells an NTFS volume it's a removable one so windows will stop writecaching the volume, but bugger if i can remember where that setting is......

    Interesting. Off to google if there are any registry switches controlling the behavior of ExFAT.

    @Tsaukpaetra said:

    Well, some people have apparently done some benchmarks already.

    For the most part, it seems merely reading/writing files is roughly the same (or slightly worse with exFAT).

    Unless you're doing pretty intensive deadline I/O, I don't think it will matter too much in real usage scenarios.

    Yeah, I've seen these. That's why the results are so confusing.

    I tried just copying a large file, and the speeds are comparable.

    @Hanzo said:

    I've experienced problems under Windows with directories with a large number of entries. That slowed down the file system to no end. Can't remember which fs, though. Do you perhaps have very large directories?

    It's exactly the same directory tree on both drives. Plenty of small files.

    @Adynathos said:

    Since you experience a significant difference on scanning the metadata but not on file read/write, it may be due to the different ways of storing/accessing metadata on those filesystems.

    Yeah. The question is, is it? And is there anything I can do about it? And why haven't the benchmarks online caught this?


  • Impossible Mission Players - A

    @cartman82 said:

    Yeah. The question is, is it?

    Eh, I'm going to say, "probably" and just be content that it even works cross platform. Now, if only we could test on the alter-OS you formatted the disk to be cross-compatible for...

    @cartman82 said:

    And is there anything I can do about it?
    Unlikely. Unless there's a modern version of fastdisk.exe available...

    @cartman82 said:

    And why haven't the benchmarks online caught this?
    Unique usage situation. Apparently people are more concerned with File I/O than directory reads.



  • Doesn't NTFS use a radically different directory structure than FAT?

    I do know that recovering and/or repairing a corrupted file system is far easier with FAT than with NTFS.

    Also, FAT won't give you weird permission headaches.


  • Winner of the 2016 Presidential Election

    @Adynathos said:

    Since you experience a significant difference on scanning the metadata but not on file read/write, it may be due to the different ways of storing/accessing metadata on those filesystems.

    @cartman82 said:

    Yeah. The question is, is it?

    Seems to be. From wikipedia:

    exFAT and the rest of the FAT family of filesystems does not use indexes for filenames, unlike NTFS which uses B-trees for file searching. When a file is accessed, the directory must be sequentially searched until a match is found.

    This appears to be confirmed in other places:

    The FAT file system uses a simple linked-list arrangement for storing large directories: the first few files are listed in the first cluster of the directory, and then the next files go into the next cluster, which is linked to the first, and so on. This is simple to implement, but means that every time you look at the directory you must scan it from start to end and then sort it for presentation to the user. It also makes it time-consuming to locate individual files in the index, especially with very large directories.
    To improve performance, NTFS directories use a special data management structure called a B-tree. [⋮] From a practical standpoint, the use of B-trees means that the directories are essentially "self-sorting". There is a bit more overhead involved when adding files to an NTFS directory, because they must be placed in this special structure. However, the payoff occurs when the directories are used. The time required to find a particular file under NTFS is dramatically reduced compared to an unsorted linked-list structure--especially for very large directories.

    That's talking about FAT rather than exFAT, but other documents lead me to believe the important parts aren't incorrect. (This presentation also indicates that exFAT stores file names as a set of up to 17 15-character "File Name Extension Directory Entr[ies]")

    So it seems that what you're seeing is the performance difference of a B-tree based FS (NTFS) vs. a table + linked-list based one (exFAT).

    @cartman82 said:

    And is there anything I can do about it?

    Probably not, since it seems intrinsic in the design.

    @cartman82 said:

    And why haven't the benchmarks online caught this?

    ¯\_(ツ)_/¯



  • @cartman82 said:

    It's exactly the same directory tree on both drives.

    I got that part. But as the other post suggests, it can be a problem to have large directories. Try making them smaller by adding an extra layer of directories.



  • @cartman82 said:

    is this expected with ExFAT?

    If ExFAT works much like FAT, it will end up with little directory files scattered all over the place. NTFS keeps all the directories inside the Master File Table, which it goes to some lengths to keep contiguous and optimally placed. I would not be at all surprised to learn that operations involving recursive directory tree walking run a lot faster on NTFS than on any variety of FAT.



  • Nobody yet gave the obvious reply?

    ExFAT is slower because it's FAT!

    :rimshot:



  • @cartman82 said:

    I'm contemplating moving my storage disks to ExFAT, to better facilitate using them from both Windows and Mac.

    OSX doesn't support NTFS?


  • Winner of the 2016 Presidential Election

    Boot Camp's implementation of NTFS is read only.



  • Not to mention that last I knew, any non-MS implementation that supports writes either only supports ancient versions of NTFS, or are so buggy they're not useable.


  • area_pol

    @RaceProUK said:

    Not to mention that last I knew, any non-MS implementation that supports writes either only supports ancient versions of NTFS, or are so buggy they're not useable.

    I must disagree, I read and write NTFS partitions from Linux and have not encountered any problems apart from being unable to write if Windows is hibernated.



  • Well then, it seems the situation has improved since I last looked :smile:



  • So the MFT is a b-tree. That explains why is so easily corrupted.



  • Are your drives different models? Maybe the NTFS formatted one is physically faster (higher RPM, more cache, no power-saving firmware, etc).


  • Discourse touched me in a no-no place

    @Adynathos said:

    I must disagree, I read and write NTFS partitions from Linux and have not encountered any problems apart from being unable to write if Windows is hibernated.

    I believe that's related to the journal log, which is a very twitchy format that's not really touchable if you're not MS's own implementation. If the log is empty (i.e., after a clean shutdown) then the only thing about is the long-term storage format for NTFS, and that's pretty well characterised.

    FWIW, I'd be unhappy about Windows accessing an ext4 filesystem from a live or hibernated Linux system too. Whether or not it is possible, it's a Bad Idea either way round.



  • @Dreikin said:

    That's talking about FAT rather than exFAT, but other documents lead me to believe the important parts aren't incorrect. (This presentation also indicates that exFAT stores file names as a set of up to 17 15-character "File Name Extension Directory Entr[ies]")

    So it seems that what you're seeing is the performance difference of a B-tree based FS (NTFS) vs. a table + linked-list based one (exFAT).

    Your evidence is compelling. Marked as accepted answer.

    @mott555 said:

    Are your drives different models? Maybe the NTFS formatted one is physically faster (higher RPM, more cache, no power-saving firmware, etc).

    Exact same model.

    Anyway, I tried to restart yesterday, and the entire pc froze during the bios check. Only removing the new exfat hdd would make it boot again.

    According to some forum posts, this is a common problem with my msi motherboard + wd cavier green disks. Nothing to do with exfat. Nevertheless, it throws the entire benchmark into doubt.

    Damn.



  • @dkf said:

    I believe that's related to the journal log

    Seems more likely to me that it relates to the fact that a hibernated snapshot of a running system is unlikely to have the filesystem in a clean state, as the hibernated image will almost certainly include cached filesystem structures relating to files that were open at the time hibernation was initiated. The filesystem doesn't have to be clean on waking from hibernation, as long as disk+RAM get restored to the same state they were in before it started.

    The current ntfs-3g implementation on Linux is pretty good. About the only real trouble I've ever had with it has been due to its ability to create NTFS directory entries that include characters Win32 doesn't allow. There's also a fundamental mismatch between NTFS and Unix access control models; ntfs-3g includes a bunch of stuff to help with reconciling that, but it's a little complicated to set up (you have to create an explicit mapping between Windows SIDs and Unix user IDs) so most of the time it doesn't get used. Instead, on most distros the default result of mounting an NTFS filesystem is that all NTFS access restrictions are completely ignored, and any new files get created with Full Control for Everyone NTFS permissions. This works well on external drives that get moved around from box to box.

    The ntfs-3g devs have a commercial offering for OS X.


  • Discourse touched me in a no-no place

    @flabdablet said:

    There's also a fundamental mismatch between NTFS and Unix access control models; ntfs-3g includes a bunch of stuff to help with reconciling that, but it's a little complicated to set up (you have to create an explicit mapping between Windows SIDs and Unix user IDs) so most of the time it doesn't get used. Instead, on most distros the default result of mounting an NTFS filesystem is that all NTFS access restrictions are completely ignored, and any new files get created with Full Control for Everyone NTFS permissions.

    Though many unix filesystems actually support ACLs these days, hardly any software supports them, and instead usually just assumes the simple POSIX model (which is good enough for most things). When combined with the ID mapping problem — particularly acute for external devices — it's no wonder that people just punt on the complexity most of the time. A simple hack gives better usability in practice than doing anything more accurate.

    This might be an indication that things are actually too complicated for most users on both sides of the OS divide…



  • @dkf said:

    ext4 filesystem from a live or hibernated Linux system too. Whether or not it is possible, it's a Bad Idea either way round.

    It is a bad idea. It is almost like a memory dump, and therefore cannot have a stable ABI.

    But what does hibernation/swap image have to do with fs journal? journal could/should be documented.

    EDIT: I read again, my reading comprehension is not full strength now. Do not waste your time reading this!



  • I just got bitten by this:

    Basically, 3GBTB SATA drive + MSI motherboard + ExFAT system = computer freezes before BIOS.

    BTW it took me buying a new drive to realize this.

    Great. There go my ExFAT plans.


  • Impossible Mission Players - A

    @cartman82 said:

    3GB SATA drive

    Where do you even get SATA drives that small?!

    Or perhaps you meant TB. Gotcha.



  • @cartman82 said:

    3GBTB SATA drive + MSI motherboard + ExFAT system =

    doing it wrong. ExFAT has no more support for file permissions than FAT does, so security in a Windows installation on an ExFAT drive is completely illusory.



  • @flabdablet said:

    doing it wrong. ExFAT has no more support for file permissions than FAT does, so security in a Windows installation on an ExFAT drive is completely illusory.

    The point was sharing data between OS-s. I'll be going with NTFS, as before.


  • Impossible Mission Players - A

    @flabdablet said:

    so security in a Windows installation on an ExFAT drive is completely illusory.

    I've always wondered how Windows XP did security when you installed it on a FAT32 system.
    Did it keep its own ACL table somewhere or something? (Only academically interested, I'm not going to install XP just to investigate this!)



  • @Tsaukpaetra said:

    Did it keep its own ACL table somewhere or something?

    No.

    As a working PC fixit guy I used to encounter far too many brand-name machines with FAT32 OEM XP images. This happened because Microsoft's early unattended installation tools were just horribly broken, if I'm remembering them right. Took them a long time to release something that didn't involve being started from DOS, formatting the disk with FAT32, then running an NTFS conversion step after the actual Windows installation had completed.

    Creating limited user accounts on such installations was completely pointless, and defragging was positively painful.



  • I suppose you can try using ReFS instead flees while laughing maniacally

    Inb4: "The Bad Ideas thread is :arrow_up::arrow_up::arrow_down::arrow_down::arrow_left::arrow_right::arrow_left::arrow_right::b::a:"



  • Something kinda weird I've seen on NTFS vs. ExFAT is that anything watching for changes (Grunt, etc.) uses no idle CPU time on NTFS, but a consistent 5-20% on ExFAT depending upon directory layout and size. Assuming NTFS has optimizations for this ExFAT doesn't and ExFAT requires some kind of dirty check.



  • It's more that NTFS triggers change events that the OS and programs can respond to, but with ExFAT you have to rely on polling



  • Why can't the OS know when it changes a file on a local filesystem?



  • Who said it doesn't?



  • Well, Linux knows what's going on on its local filesystems, but maybe Windows doesn't have a similar API available.



  • Right, and that changes what exactly?



  • At the very least, it changes @ben_lubar's post count.



  • @ben_lubar said:

    Well, Linux knows what's going on on its local filesystems, but maybe Windows doesn't have a similar API available.

    Maybe the API requires support from the filesystem driver?



  • Which was presumably written by Microsoft, who also wrote the API?



  • @dse Except for the fact that Microsoft CREATED the exFAT file system too. They make royalties off of exFAT by licensing it. Why would they make something that makes them money inferior on purpose?! That doesn't make sense. Basically your conspiracy is bunk. Each simply has it's designed purpose. In relatively short terms, NTFS is meant for Windows OS specific partitions and exFAT is meant for external storage and cross-platform compatibility.

    Companies have to pay Microsoft to use exFAT just like they have to pay Apple for the forced use of the lightning port on the new iPhone 7. Companies like Apple and Microsoft like money. They tend to favor things that contribute to that mentality.


  • sockdevs

    @SpectreAvenger holy fbnecromac batman!



  • @Adynathos said in Is ExFAT slower than NTFS?:

    apart from being unable to write if Windows is hibernated

    Which unfortunately now means "pretty much all the time", thanks to "fast startup" and other weird stuff Windows does.

    Edit: didn't notice the necro since we don't have the helpful "x months ago" dates anymore.



  • @cartman82 said in Is ExFAT slower than NTFS?:

    The point was sharing data between OS-s. I'll be going with NTFS, as before.

    I always wonder why the ext4 drivers for Windows aren't more popular. Seems like a much better choice from a technical point of view (not relying on reverse-engineered and undocumented stuff).


  • sockdevs

    @anonymous234 said in Is ExFAT slower than NTFS?:

    I always wonder why the ext4 drivers for Windows aren't more popular.

    Windowsitis?

    also IIRC permissions with the ext* drivers for wondows were juuuuuuuuust odd enough to annoy the crap out of me.....

    but that was windoze XP days last i used that driver.


  • area_pol

    @anonymous234 said in Is ExFAT slower than NTFS?:

    Which unfortunately now means "pretty much all the time", thanks to "fast startup" and other weird stuff Windows does.

    The "fast boot" can be easily disabled and then you can mount Windows partitions from Linux. I do it all the time.

    @anonymous234 said in Is ExFAT slower than NTFS?:

    I always wonder why the ext4 drivers for Windows aren't more popular.

    Maybe not popular, but available and actively developed.

    Their website is terrible so see the program here:
    0_1479761779454_Ext2fsd.PNG


  • sockdevs

    @Adynathos said in Is ExFAT slower than NTFS?:

    Maybe not popular

    @Adynathos said in Is ExFAT slower than NTFS?:

    Their website is terrible

    hmm... unpopular? with a shit website?

    0_1479762040594_upload-28d46193-6b23-4004-a398-6791dc881284


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.