Announcement

Collapse
No announcement yet.

exFAT Driver With Linux 6.13 Reduces FAT Chain Traversal For Better Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • exFAT Driver With Linux 6.13 Reduces FAT Chain Traversal For Better Performance

    Phoronix: exFAT Driver With Linux 6.13 Reduces FAT Chain Traversal For Better Performance

    For those making use of the Microsoft exFAT file-system on Linux systems, the upcoming Linux 6.13 kernel brings an optimization that will help some operations by reducing the FAT chain traversal...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    That's nice, along with those recent ext4 performance improvements, but I'm waiting for Paragon to fix the ntfs3 driver so that it stops corrupting ntfs filesystems. I had to blacklist the driver and revert to ntfs-3g for reliability. I don't understand why ntfs3 was made the default ntfs driver in Ubuntu when it's clearly not finished cooking.

    Comment


    • #3
      The language of the commit is fairly opaque even if one is familiar with the on-disk structures of the FAT file systems. But from what I can tell this isn't likely to speed up anything but directory traversals where you have a fairly large number of files or considerable depth to the directory structure. You still have to follow fragmentation chains in files regardless. While access latency across flash devices tend to be flat, you still incur a cost each time you have to jump to the next link in the structure, which due to backwards compatibility reasons, is in at least two places on FAT32 and exFAT formatted storage devices. If it's a flat or shallow structure with few entries it'll all be at the beginning of the filesystem. If it requires more space, the additional tree information will have a pointer at the end of the first (legacy) structure that points to where the next part of the structure resides, usually near the logical end of the file system. If this is complex when you have to make changes, you incur increasing costs to chain traversal. This reduces that time such that you need not traverse the tree chain itself to find the last cluster. So simple storage, where you have few files or shallow structures or both won't see any improvement. Complex directory structures that require chains to store the information will see a proportional decrease in time needed to complete the necessary changes to those trees, whether it's moving, deletion, etc. You'll mostly notice the problem if you try to eject a USB drive after a big move or delete operation. Dumping files to the device will still take the same amount of time.

      Also take note, that while access times tend to be flat, throughput and operations queueing can vary depend on a sequential access or random access. SSD is optimized to favor sequential access while chain traversals are random which drops the number of operations that can be completed in a given amount of time considerably. (Which makes it not strictly true that SSDs are fragmentation agnostic.)
      Last edited by stormcrow; 27 November 2024, 11:38 PM.

      Comment


      • #4
        I'm not sure about the technicalities. But in my naive estimation, slim chains will always traverse much faster that FAT chains.

        Comment


        • #5
          Originally posted by lowflyer View Post
          I'm not sure about the technicalities. But in my naive estimation, slim chains will always traverse much faster that FAT chains.
          time to move to SlimFS!


          Comment


          • #6
            Originally posted by cynic View Post
            KetoFS surely?

            Comment


            • #7
              Nice, as it looks like, we will never quite get rid of some fat filesystems.

              Originally posted by gnarlin View Post
              I don't understand why ntfs3 was made the default ntfs driver in Ubuntu when it's clearly not finished cooking.
              This is why I left Ubuntu as they incorporate a lot of under cooked stuff into their LTS releases. The last straw was the Firefox snap, as it didn't allow using Kerberos/SPNEGO authentication https://bugzilla.mozilla.org/show_bug.cgi?id=1734791.

              Comment


              • #8
                Originally posted by cynic View Post
                Originally posted by geerge View Post
                KetoFS surely?


                Can somebody quickly write a paper about it? KetoFS seems to be a very low hanging fruit.

                PS: the `Request Rejected` on the ieee link is sort of indicative.

                Comment


                • #9
                  Originally posted by gnarlin View Post
                  That's nice, along with those recent ext4 performance improvements, but I'm waiting for Paragon to fix the ntfs3 driver so that it stops corrupting ntfs filesystems. I had to blacklist the driver and revert to ntfs-3g for reliability. I don't understand why ntfs3 was made the default ntfs driver in Ubuntu when it's clearly not finished cooking.
                  In fairness I do not think there is any NTFS driver on any system that does not currupt the FS. Not even the windows driver manages that.
                  But, from my usage as far, the paragon contributed driver worked well every time. Not any worse than windows itself.

                  Comment


                  • #10
                    "exFAT Driver With Linux 6.13 Reduces FAT Chain Traversal For Better Performance"

                    Some "light" humor to start the day...

                    Comment

                    Working...
                    X