Live data from Hacker News

exFAT in the Linux kernel

cloudblogs.microsoft.com

51–60 of 280 posts

Re: exFAT in the Linux kernel

#51
post #20
post #3

I don't mean for this question to sound inflammatory but I can't help but think: why does this matter? You can already use exFAT on Linux via FUSE, and as pointed out by VentureBeat: > To be clear, Microsoft isn’t open-sourcing exFAT — but it is making sure anyone building with Linux can use it. 'It’s important to us that the Linux community can make use of exFAT included in the Linux kernel with confidence.' exFAT i…

It will be in the "real" kernel soon, here is a patch I submitted adding it: https://lore.kernel.org/lkml/20190828160817.6250-1-gregkh@li... And yes, this is _much_ better than using a FUSE interface to the filesystem.

For the 99% of people reading who don't know the kernel as well as you (seriously) can you explain why this is the case?

Does a userspace filesystem driver lose a lot of performance to context switching, or is there something unique to filesystems that slows them down in user space?

Re: exFAT in the Linux kernel

#52
post #36

Earlier quoted context omitted.

.... on FAT partitions

Sorry, dumb question. :) I guess I never noticed a problem because either I mostly use ext3/4, or I am so used to using legally dubious drivers that I forgot they were there. I mean, who ever gives you a FAT formatted disk? I don't have floppy drive anyway :p

If you ever interact with people running Windows (or even OSX) all of their thumbdrives will be formatted with FAT unless they recently used it make a Linux boot disk after installing a later version of windows 10 that has extx support and didn't notice.

If OSX and EFI had out of the box support for Linux filesystems we could at least stop using FAT on pendrives. I personally will look forward to that.

Re: exFAT in the Linux kernel

#53
post #20

Earlier quoted context omitted.

It will be in the "real" kernel soon, here is a patch I submitted adding it: https://lore.kernel.org/lkml/20190828160817.6250-1-gregkh@li... And yes, this is _much_ better than using a FUSE interface to the filesystem.

For the 99% of people reading who don't know the kernel as well as you (seriously) can you explain why this is the case? Does a userspace filesystem driver lose a lot of performance to context switching, or is there something unique to filesystems that slows them down in user space?

> Does a userspace filesystem loose a lot of performance...

Yes.

Try the two versions out, and see for yourself if you are curious.

Re: exFAT in the Linux kernel

#55

Almost every months Microsoft make a more or less major gift to the open source community, this is beautiful. They are the new "benevolent" Google and it's no surprise they're now the number one open source contributor of the world.

They already extorted Android OEMs using exFat patents for billions, might as well try to look nice.

As much as I hate the patent bullying Android should have never used FAT for ANYTHING. The stupidity around that continues to make everyone's lives hard to this day.

Re: exFAT in the Linux kernel

#56

Any news on NTFS ?

NTFS-3g is pretty good and support on Linux is definitely a lot better than it used to be. Still, official (or officially supported/documented) support would be really nice.

Honestly I hope even Windows abandons NTFS soon. It's the worst part of using Windows. e.g. Try and develop any Node project on Windows and it's painful - takes literally minutes to delete the node_modules folder whereas on Linux/Mac it takes seconds. It only recently got long pathname support (260+ chars long)...

Re: exFAT in the Linux kernel

#57
post #35

Does this affect anything outside the Linux kernel? Will *BSDs be able to use the specs without patent fears? What about microcontrollers, and the Arduino community?

No. The OIN promise only applies to Linux-based systems.

What defines a "Linux-based system"? Does Android count? Would VMWare's VSphere ESXi hypervisor count? Would a unikernel running on a pared-down Linux rump-kernel (if such a thing were made) count?

Re: exFAT in the Linux kernel

#58
post #3

I don't mean for this question to sound inflammatory but I can't help but think: why does this matter? You can already use exFAT on Linux via FUSE, and as pointed out by VentureBeat: > To be clear, Microsoft isn’t open-sourcing exFAT — but it is making sure anyone building with Linux can use it. 'It’s important to us that the Linux community can make use of exFAT included in the Linux kernel with confidence.' exFAT i…

Because Fuse is slooow - I've had an external Exfat drive mounted on Raspberry Pi 4 and writing large amount of data would pretty much max out the CPU. Ext3/4 has no such issue, I can write to it for days without taxing the CPU. Apparently it's a known problem with Fuse partitions, NFTS-3G has the same problem.

Re: exFAT in the Linux kernel

#59
post #35

Does this affect anything outside the Linux kernel? Will *BSDs be able to use the specs without patent fears? What about microcontrollers, and the Arduino community?

No. The OIN promise only applies to Linux-based systems.

How does that work ? OIN applies to corporations. What if you aren't a member ? Or is the actual code in the linux kernel going to have a patent grant ? But MS may not be the one committing the code. So will they just add a patent grant header irrespective of who commits the code ?

Re: exFAT in the Linux kernel

#60
post #57

Earlier quoted context omitted.

No. The OIN promise only applies to Linux-based systems.

What defines a "Linux-based system"? Does Android count? Would VMWare's VSphere ESXi hypervisor count? Would a unikernel running on a pared-down Linux rump-kernel (if such a thing were made) count?

According to http://en.swpat.org/wiki/GPLv2_and_patents , GPLv2 includes an implicit patent grant

So my guess would be that the definition of "derivative work" would apply.

Post reply on HN