Announcement
Collapse
No announcement yet.
An Alternative exFAT Linux File-System Driver Based On Samsung's sdFAT
Collapse
X
-
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.
-
Originally posted by skeevy420 View PostOnly reason I said F2FS is because it's a file system designed for flash drives.
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
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.
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:
-
Originally posted by starshipeleven View PostMostly 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.
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:
-
Originally posted by skeevy420 View PostWhy 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)?
More like F2FS or even XFS (thinking Stratis).
Leave a comment:
-
Originally posted by calc View PostAnd journaling onto flash is generally considered a bad idea due to the much increased writes.
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.
- Likes 2
Leave a comment:
-
Originally posted by skeevy420 View PostOn another note, is a 4TB thumb drive/sd card/whatever without a journaled file system necessarily a good thing in the long run?
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.
- Likes 3
Leave a comment:
-
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:
-
Originally posted by birdie View PostI 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?
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 PostRandom 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.
Last edited by illwieckz; 15 September 2019, 12:22 PM.
- Likes 6
Leave a comment:
-
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?
- Likes 1
Leave a comment:
-
Originally posted by birdie View PostWhat? 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?
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 PostRandom 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).
This thread has nothing to do with FUSE.
Your post is absolutely out of topic.
- Likes 12
Leave a comment:
Leave a comment: