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

31–40 of 109 posts

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

#31

Post by noAnswer »

jaclaz wrote: post #28
ninefathom wrote: post #9

I'm a bit puzzled as to how split files with name standardization is an "extension." It seems to me that SEGGER is simply proposing a de facto file naming convention, and offering a few free tools (including a few abstraction drivers) to encourage adoption. Can somebody fill me in, here- where's the value in what SEGGER is proposing, as opposed to what the entire IT community has already been doing for decades?

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.

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

#33

Post by NotYourLawyer »

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 patents.”

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

#34

Post by mschuster91 »

chasil wrote: post #17
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…

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…

> Is it really necessary to keep dragging FAT along?

Anything involving embedded and without deep pockets has no other option, FAT (sadly) still is the least common denominator. Some speak ExFAT, but not sure how good the tooling support is outside of Microsoft, and there are still patent concerns.

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

#35

Post by slavik81 »

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

The patent will also expire in 2027 [1]. We can look forward to it being entirely unencumbered at that point.

https://patents.google.com/patent/US20090164440?oq=US2009164...

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

#36

Post by LinAGKar »

jchw wrote: post #24
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.

Now that exFAT is "open", I've seen it cropping up much more often. SD cards often ship with it, especially large ones.

That happened before it was open. exFAT is the standard filesystem on SDXC

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

#37

Post by kreco »

chasil wrote: post #17
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…

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.

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

#38

Post by netsharc »

ninefathom wrote: post #9

I'm a bit puzzled as to how split files with name standardization is an "extension." It seems to me that SEGGER is simply proposing a de facto file naming convention, and offering a few free tools (including a few abstraction drivers) to encourage adoption. Can somebody fill me in, here- where's the value in what SEGGER is proposing, as opposed to what the entire IT community has already been doing for decades?

Edit: I guess my first look is wrong, on second look, it appears it needs their own filesystem driver. If the hack as I wrote would've worked, it would've been very clever, and dangerous...

> de facto file naming convention

From a first look, like it's using Microsoft's own hack of long file names[1] to create file entries that look like they belong to 1 file. A file that has a long file name (more than the 8+3 character limit) is actually several file entries, but they're empty files. Seems like the tool is creating non-empty files instead, that Windows is chaining together as one.

[1] https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#...

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

#39

Post by vetinari »

mikece wrote: post #23
cmurf wrote: post #8

Earlier quoted context omitted.

The industry could have used UDF. Derived from ISO 9660, but it supports read-write random access storage. I'm guessing they didn't if FAT12/16/32->exFAT driver changes are comparatively simple, and/or results in a smaller code base to support FAT32 and exFAT on the same device (e.g. a camera).

And on a camera that costs anywhere from USD$1000 to USD$6500 does the cost of an exFAT license really matter?

Yes, it does.

If you manufacture 100K of them, and save 10 dollars on every piece, you got an extra million in savings.

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

#40

Post by matja »

phkahler wrote: post #32

The question I have is, why Segger? When I saw this I was like "the debugger company?!?!" Clearly this wouldn't fall under their business, so it makes sense for them to open it up, but why did they do it in the first place?

They have an entire RTOS ecosystem which supports a gazillon different microcontrollers.
Post reply on HN