Announcement

Collapse
No announcement yet.

An Alternative exFAT Linux File-System Driver Based On Samsung's sdFAT

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

  • #11
    Originally posted by illwieckz View Post

    This is not a FUSE based filesystem, you probably miss older articles:
    ....
    What? exfat has been a fuse FS in most Linux distros so far and https://github.com/arter97/exfat-linux shows how bad it is. Can you even read?

    Comment


    • #12
      Originally posted by birdie View Post
      Can you even read?
      Still trying to make friends, I see?

      Comment


      • #13
        Originally posted by birdie View Post
        What? exfat has been a fuse FS in most Linux distros so far and https://github.com/arter97/exfat-linux shows how bad it is. Can you even read?
        There is a FUSE exFAT filesystem driver and a non-FUSE exFAT filesystem driver.

        Both have their own issues.

        This thread is about the non-FUSE implementation so the FUSE issues are out of topic.

        No one denied the issues about the non-FUSE implementation, and I've read them.

        Reading about them or not, even being able to read or not is absolutely unrelated to the fact your post was out of topic.

        I quote your post as a whole:

        Originally posted by birdie View Post
        Random IO benchmarks clearly show how horribly slow and inefficient FUSE based filesystems are in general. What's more they cannot work without /tmp backstore (maybe not all but the ones I've tested) which also limits file sizes in case the user mounts tmpfs to /tmp (I've been doing that for the past 15 years or more).
        Your post in this thread only talks about FUSE.

        This thread has nothing to do with FUSE.

        Your post is absolutely out of topic.

        Comment


        • #14
          I don't know what kind of weed you're smoking but I just made a remark specifically about FUSE in my very first comment. You could have simply ignored it if you don't think it belongs to this discussion. What's wrong with people nowadays?

          Comment


          • #15
            Originally posted by birdie View Post
            I don't know what kind of weed you're smoking but I just made a remark specifically about FUSE in my very first comment.
            Yeah, that's precisely why it's out of topic.

            You could have simply ignored it if you don't think it belongs to this discussion. What's wrong with people nowadays?
            If it does not belong to the discussion the only effort to do is to not post it at first, this way only one ignore his own post instead of everyone-but-one has to ignore it.

            What you do is similar to someone who would ask for having the right to poo in the street by saying others would just have to avoid it.

            It's not only about fairness, cleanness and savoir vivre, it's about saving: only one makes the effort instead of everyone-but-one make the effort.

            Note that your post would belong to the discussion if you wrote instead:

            Originally posted by birdie View Post
            Random IO benchmarks clearly show how horribly slow and inefficient FUSE based filesystems are in general. What's more they cannot work without /tmp backstore (maybe not all but the ones I've tested) which also limits file sizes in case the user mounts tmpfs to /tmp (I've been doing that for the past 15 years or more).

            That's why this non-FUSE driver is welcome, whatever its current status.
            Or something like that.

            Last edited by illwieckz; 09-15-2019, 12:22 PM.

            Comment


            • #16
              I have a work laptop that I have to have Windows on for occasional compatibility with what everybody else is using. I dual-boot it, and typically stay in Fedora Linux. It has 1 m.2 slot for storage, and that has a 1TB SSD in it.

              I do a lot of work with QEMU/KVM/VMWare and sometimes have to do some on Windows and some in Linux, so I need a shared data partition. My solution was to take up less than half the drive with OS + Home partitions, then have a large shared partition that both Windows and Linux could read+write to. I tried exfat through the exfat FUSE, but quickly abandoned it when I found I couldn't use symlinks (at least with the options I was doing at the time). I then moved to NTFS, but my VMs/emulations would pause and hiccup on iowait as the FUSE NTFS couldn't keep up with even XP and prior versions of Windows.

              This morning I did some experiments with this, and there is a symlinks mount option that seems to permit symlinks with exFAT (symlink=1), and this is almost as fast as EXT4 according to the author's benchmarks, so it should alleviate the hiccups and allow my workflow to actually operate.

              BTW, Windows 10 (1903) doesn't have any idea what to do with the symlinks, but that isn't necessary in my current use-cases (Windows does have mklink and can do sym and hard links under NTFS, but that doesn't seem to apply here).
              Last edited by Min1123; 09-15-2019, 01:04 PM. Reason: Added update about how Win10 1903 sees and interacts with the symlinks.

              Comment


              • #17
                Originally posted by skeevy420 View Post
                On another note, is a 4TB thumb drive/sd card/whatever without a journaled file system necessarily a good thing in the long run?
                While exFAT allows for larger filesystems than 2TB the more important part is that it allows for larger individual files than 4GB. It only takes a few minutes of 4K video to exceed 4GB on good cameras.

                FAT32 also isn't ideal for use on over 32GB filesystems, which is why exFAT was mandated for larger SD cards, and also why you can't easily create larger FAT32 filesystems on Windows.

                And journaling onto flash is generally considered a bad idea due to the much increased writes.

                Comment


                • #18
                  Originally posted by calc View Post
                  And journaling onto flash is generally considered a bad idea due to the much increased writes.
                  This ceased to be an issue long ago even for USB flash drives.

                  I know a bunch of people who reformatted their flash drive as NTFS (yes windows users) because of the silly 4GB limitation of FAT32 and nothing ever went wrong in like 5 years of use.

                  Comment


                  • #19
                    Originally posted by skeevy420 View Post
                    Why can't we ditch FAT for something newer? Does anyone actually use FAT for anything if it isn't forced on them (EFI, certain SD card readers, etc)?
                    Mostly flash drives and other devices that need to be inter-operable and I don't feel like formatting NTFS.

                    More like F2FS or even XFS (thinking Stratis).
                    Neither can be read outside of Linux desktop systems, also F2FS is a dumpster fire and I'm not trusting it with data.

                    Comment


                    • #20
                      Originally posted by starshipeleven View Post
                      Mostly flash drives and other devices that need to be inter-operable and I don't feel like formatting NTFS.

                      Neither can be read outside of Linux desktop systems, also F2FS is a dumpster fire and I'm not trusting it with data.
                      Same here other than replace NTFS with XFS or EXT4.

                      Only reason I said F2FS is because it's a file system designed for flash drives. IHMO, it makes sense to pick a file system designed for flash drives for the flash drive standard. XFS is the backing file system of Stratis, a fustercluck of Linux file system tech all unified together to compete with ZFS....and it looks very promising; that combined with the recent XFS feature revival makes it one of the best Linux file systems for a project to pick from regardless of the reason or purpose.

                      On the Linux desktop comment, that becomes a moot point if the corporations backing various Linus projects agree to use XYZ file system and then fund the porting/rewriting/whatever.

                      The paranoid conspiracy theory side of me says MS made FAT more permissive to preempt other corporations undermining one of their basic standards and prevent them from making the switch to EXT4 or F2FS since they were getting pretty comfortable using and supporting those file systems with Android, Chromebooks, and Linux Laptops. Put a dedicated team behind it and EXT4 on Windows is a done deal which would then undermine MS in a 2nd way -- EXT4 being an option would mean that NTFS would no longer be the file system of choice for Windows Servers. I can almost guarantee we're getting exFAT because any suitable FAT32 replacement ported over from Linux Land would also replace NTFS and that's something that MS can't allow to happen until WinFS (or whatever it's called now) is actually ready for release and mass use.

                      Comment

                      Working...
                      X