Announcement

Collapse
No announcement yet.

Linux's exFAT File-System Driver Can Now "FSCK" As Fast As Windows

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

  • Linux's exFAT File-System Driver Can Now "FSCK" As Fast As Windows

    Phoronix: Linux's exFAT File-System Driver Can Now "FSCK" As Fast As Windows

    Samsung engineers responsible for the modern exFAT file-system driver for Linux have updated the adjoining "exfatprogs" user-space programs around this file-system. Notable to exfatprogs-1.0.4 is much faster "fsck" file-system checking support...

    http://www.phoronix.com/scan.php?pag...AT-Progs-1.0.4

  • #2
    Wait I thought it was chkdsk on Windows? (not fsck?)

    Comment


    • #3
      Now that Microsoft has joined the Open Invention Network, why hasn't there been any push to upstream an NTFS driver? I believe the day they joined the OIN, a patchset went out for exFAT, but no NTFS.

      Comment


      • #4
        Originally posted by doublez13 View Post
        Now that Microsoft has joined the Open Invention Network, why hasn't there been any push to upstream an NTFS driver? I believe the day they joined the OIN, a patchset went out for exFAT, but no NTFS.
        Probably because for Linux users, having first-class exFAT support is much more urgent than NTFS. Dual boot Linux/Windows installations seem to be the only real major use case for NTFS in Linux but that is much less prevalent these days.

        Another possibility is that NTFS is ancient code with lots of accumulated cruft that has probably never been revised or optimised since. I've heard second-hand stories about especially the mutex / locking architecture being borderline insane. At the same time, NTFS is a core part of their expensive Server OS offerings and they may not want to disclose such gory reality to their "enterprise" customers. This is pure speculation of course.

        Comment


        • #5
          Oh, FSCK!

          Comment


          • #6
            It's a good idea to chkdsk before and after a fsck.

            Comment


            • #7
              Originally posted by jacob View Post

              Probably because for Linux users, having first-class exFAT support is much more urgent than NTFS. Dual boot Linux/Windows installations seem to be the only real major use case for NTFS in Linux but that is much less prevalent these days.

              Another possibility is that NTFS is ancient code with lots of accumulated cruft that has probably never been revised or optimised since. I've heard second-hand stories about especially the mutex / locking architecture being borderline insane. At the same time, NTFS is a core part of their expensive Server OS offerings and they may not want to disclose such gory reality to their "enterprise" customers. This is pure speculation of course.
              That and both ZFS and BTRFS have up-and-coming Windows drivers. At this point in time since NTFS support is good enough at the userspace level I suspect a portion of us dual-booting Linux geeks would rather just wait on one of those to mature and use it over waiting on a (MS provided) NTFS driver in the kernel...or they've moved on to using dual GPUs and virtualization.

              Comment


              • #8
                unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep....

                Comment


                • #9
                  Originally posted by doublez13 View Post
                  Now that Microsoft has joined the Open Invention Network, why hasn't there been any push to upstream an NTFS driver? I believe the day they joined the OIN, a patchset went out for exFAT, but no NTFS.
                  Possibly because you have not yet completed your work to take the existing open source R/W driver and make it kernel ready (the current one is FUSE, which has completely different design point, and highly likely does not met current kernel coding standards)? And the authors of the existing open source FUSE R/W driver have a commercial product, so I am not sure they are going to be motivated to do the work themselves any time soon. Remember that what is the current long term exFAT kernel implementation (not the initial introduction into staging of an older leaked variant of the driver) has a corporation behind it that wanted to end out-of-tree maintenance (Samsung), so was motivated to get the work done. So, to turn the question around, as open source is about scratching your itch and contributing, when will your work to convert the open source FUSE driver to an acceptable kernel contribution be ready?

                  Comment


                  • #10
                    Nothing can FSCK as fast as Windows. It's just too easy to FSCK Windows.

                    Comment

                    Working...
                    X