Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BigFAT – Backward compatible FAT extension for unlimited file size

segger.com

Post reply on HN
Print view View original

41–50 of 109 posts

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#41

Post by BearOso »

georgyo wrote: post #22
mort96 wrote: post #19

Earlier quoted context omitted.

Camera manufacturers and SD card manufacturers can't start shipping SD cards formatted with btrfs until Windows supports it out of the box. They can start shipping SD cards formatted with FAT32 and software/firmware which reads and writes FAT32+BigFAT.

More specifically, they need a filesystem that both Windows and MacOS can read. No one wants to take their SD card to a friend's computer and have it not work for reasons they won't understand. The shared set there is basically just fat and exfat. If Microsoft and Apple collaborated on a new filesystem, or even just supported it, then we might have a possible successor. However even with that, the millions of already…

Remember last time they tried a universal media filesystem with UDF? It was implemented in the most incompatible ways as a token gesture by both Microsoft and Apple. These companies want their own, patented, proprietary fs so they can maintain lock-in.

The only way to get a universal standard is to have the community do it and have enough people use it that the big companies have to capitulate.

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#42

Post by School-Cotton »

mort96 wrote: post #19
chasil wrote: post #17

Earlier quoted context omitted.

There are so many good filesystems out there. Is it really necessary to keep dragging FAT along? ReactOS is using btrfs, which has so many useful options that FAT will never see (zstd, xxhash, flash-aware options, snapshots, send/receive, etc.). This is positioned both for Linux and Windows. Microsoft itself restrains ReFS to enterprise use, and btrfs offers so much more functionality. We should stop using a file sys…

Camera manufacturers and SD card manufacturers can't start shipping SD cards formatted with btrfs until Windows supports it out of the box. They can start shipping SD cards formatted with FAT32 and software/firmware which reads and writes FAT32+BigFAT.

If they can ship software that reads BigFAT, why can’t they ship software that reads btrfs?

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#43

Post by NelsonMinar »

mort96 wrote: post #10

I like the idea. Making it backwards compatible with FAT means that, in principle, regular FAT filesystem implementations could be transparently changed to support big fat files (hehe) transparently. However, reading the spec, it doesn't look fully backwards compatible? It seems like there are file structures which are possible to represent in FAT which aren't possible to represent in BigFAT. In FAT, I could have a 4…

What FAT32 filesystem in the real world has a file named "foo.000.BigFAT" on it?

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#44

Post by chasil »

kreco wrote: post #37
chasil wrote: post #17

Earlier quoted context omitted.

There are so many good filesystems out there. Is it really necessary to keep dragging FAT along? ReactOS is using btrfs, which has so many useful options that FAT will never see (zstd, xxhash, flash-aware options, snapshots, send/receive, etc.). This is positioned both for Linux and Windows. Microsoft itself restrains ReFS to enterprise use, and btrfs offers so much more functionality. We should stop using a file sys…

Nothing beats the simplicity of FAT. Btrfs has a lot of bugs while being active for a long time. This is mostly related to its complexity. If I'm going to implement a filesystem for a custom hardware I would definitely not chose btrfs.

If you want snapshots, dedup, transparent compression, and scrubs then you have precisely three open and/or available choices: ZFS, btrfs, and ReFS.

By all means, choose the Microsoft solution, because patent licensing is good for everyone.

And the bug myth past into history years ago.

"So, we'll repeat this once more: as a single-disk filesystem, btrfs has been stable and for the most part performant for years."

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#45

Post by guipsp »

chasil wrote: post #44
kreco wrote: post #37

Earlier quoted context omitted.

Nothing beats the simplicity of FAT. Btrfs has a lot of bugs while being active for a long time. This is mostly related to its complexity. If I'm going to implement a filesystem for a custom hardware I would definitely not chose btrfs.

If you want snapshots, dedup, transparent compression, and scrubs then you have precisely three open and/or available choices: ZFS, btrfs, and ReFS. By all means, choose the Microsoft solution, because patent licensing is good for everyone. And the bug myth past into history years ago. "So, we'll repeat this once more: as a single-disk filesystem, btrfs has been stable and for the most part performant for years." htt…

But I just want 5GB files

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#46

Post by [deleted] »

NotYourLawyer wrote: post #33
CodesInChaos wrote: post #30

Are the exFAT patents still a problem nowadays? > exFAT was a proprietary file system until 2019, when Microsoft released the specification and allowed OIN members to use their patents. https://en.wikipedia.org/wiki/ExFAT#Legal_status

> We also support the eventual inclusion of a Linux kernel with exFAT support in a future revision of the Open Invention Network’s Linux System Definition, where, once accepted, the code will benefit from the defensive patent commitments of OIN’s 3040+ members and licensees. I don’t know exactly what that means. But it sounds like something different from “we hereby grant everybody a license to any and all exFAT pate…

[deleted]

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#47

Post by jaclaz »

noAnswer wrote: post #31
jaclaz wrote: post #28

Earlier quoted context omitted.

I had the same impression, I cannot see how it is different from the tools that allow file splitting (for later archiving on floppies. CD's, DVD's, etc.) that exist since forever, when/if implemented in OS filesystem drivers then it will be more "transparent", but until then it seems to me not different from multi-part archives, such as rar or similar. If I may it would make more sense (to me at least) to use a direc…

Using split, cat or rar doesn't allow random access.

But also this "extension" doesn't seem like allowing it.

On the contrary (but it is a specific "niche" case) the mentioned vmdk split format allows to mount the vmdk same as monolithic, with full random access.

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#48

Post by chasil »

guipsp wrote: post #45
chasil wrote: post #44

Earlier quoted context omitted.

If you want snapshots, dedup, transparent compression, and scrubs then you have precisely three open and/or available choices: ZFS, btrfs, and ReFS. By all means, choose the Microsoft solution, because patent licensing is good for everyone. And the bug myth past into history years ago. "So, we'll repeat this once more: as a single-disk filesystem, btrfs has been stable and for the most part performant for years." htt…

But I just want 5GB files

Microsoft just wants a check from you.

We are all forced to pay for this ancient software every time we buy a device that uses it.

Wouldn't this money be better used elsewhere?

https://en.m.wikipedia.org/wiki/File_Allocation_Table#Patent...

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#49

Post by scohesc »

Would it not be possible to create a filesystem with modern capabilities but with backwards compatibility with FAT? Why can't we just have "legacy" commands built into the ReFS filesystem that process any FAT filesystem access?

I'm very ignorant to this but I'd love some insight from someone vastly more knowledgeable than me.

Re: BigFAT – Backward compatible FAT extension for unlimited file size

#50

Post by guipsp »

School-Cotton wrote: post #42
mort96 wrote: post #19

Earlier quoted context omitted.

Camera manufacturers and SD card manufacturers can't start shipping SD cards formatted with btrfs until Windows supports it out of the box. They can start shipping SD cards formatted with FAT32 and software/firmware which reads and writes FAT32+BigFAT.

If they can ship software that reads BigFAT, why can’t they ship software that reads btrfs?

Because you only need the software for >4gb files and block level access requires root or admin usually. This is can be fully userspace if your OS already supports Fat32 (it does).
Post reply on HN