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

  • TheLexMachine
    replied
    F2FS has at least another five years of meat-beating and ball-rolling development before it's stable and proven viable enough for mass-deployment in consumer Windows and Apple systems. Over that time, the market will transition to laptops and desktops with NVME SSD boot drives as the default storage choice, so it will be a useful addition to the respective OS toolbox.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by skeevy420 View Post
    Only reason I said F2FS is because it's a file system designed for flash drives.
    I agree on the principle. I just said that it is a dumpster fire outside of Android and I don't want to use something that is less safe than Fat32.

    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.
    Port of what to what.

    The paranoid conspiracy theory side of me says MS made FAT more permissive to preempt other corporations undermining one of their basic standards
    Your conspiracy theory side is wrong.

    Everyone and their dog bought exFAT licenses long ago and have been using them ever since. exFAT is part of the standard for bigger/faster SDcards.

    The war is long since won, exFat is a standard with as wide usage as FAT32. There is no need to fight anymore. It's low-importance enough that they can dump what is left of its patents for a simple PR move.

    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.
    There isn't a whole lot of need for something better than NTFS, bulk of Windows servers aren't going to run so performance-critical applications that can't be solved by the end user with enterprise SSDs.

    Which is why the ReFS filesystem isn't going nowhere, nor is the "software raid" component of Windows (Storage Spaces), that is there since Win7 and everyone keeps using RAID cards or even shit-grade Intel Matrix RAID integrated in the motherboard (i.e. softraid disguised as hardware).

    Leave a comment:


  • skeevy420
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    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.

    Leave a comment:


  • calc
    replied
    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.

    Leave a comment:


  • Min1123
    replied
    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; 15 September 2019, 01:04 PM. Reason: Added update about how Win10 1903 sees and interacts with the symlinks.

    Leave a comment:


  • illwieckz
    replied
    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; 15 September 2019, 12:22 PM.

    Leave a comment:


  • birdie
    replied
    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?

    Leave a comment:


  • illwieckz
    replied
    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.

    Leave a comment:

Working...
X