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

21–30 of 109 posts

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

#21

Post by chasil »

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.

I guess what is needed is a BSD implementation of btrfs.

Still, something similar to fuse might help with the licensing.

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

#22

Post by georgyo »

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.

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 shipped devices won't support it. This during the transition period of many years there will still need to be support for fat.

That keeps fat the lowest common denominator and everything supporting it.

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

#23

Post by mikece »

cmurf wrote: post #8
mikece wrote: post #4

> Why not exFAT... Microsoft owns several patents, and anyone who implements or uses exFAT technology needs Microsoft's permission, which typically also includes paying fees to Microsoft. While BigFAT not being encumbered by any patents is a good thing, the camera industry have pretty much standardized on exFAT for their removable file storage format. Something I'm curious about is how a 5GB video file (quite common…

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?

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

#24

Post by jchw »

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.

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

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

#25

Post by mort96 »

chasil wrote: post #21
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.

I guess what is needed is a BSD implementation of btrfs. Still, something similar to fuse might help with the licensing.

No, what is needed is for Windows and macOS to support btrfs out of the box.

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

#26

Post by noAnswer »

JAA1337 wrote: post #12

Awesome concept, especially for academia ... but is there a value proposition? I love seeing this, don't get me wrong. I am just curious is there are any real world applications for this?

> but is there a value proposition?

Straight from their FAQ: We see emFile customers asking for solutions for bigger files. Implementing exFAT is not an option for us, as it is patent encumbered. SEGGER would need Microsoft's permission to implement and offer it, and our customers need to deal with Microsoft again to be able to use it in their products. This can be time-consuming and also expensive. We feel there should be a free alternative. The more popular BigFAT becomes, the better.

I guess using anything but FAT would make it hard for their developer base.

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

#28

Post by jaclaz »

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 directory and have a descriptor file, not entirely unlike multi-part vmdk's are implemented.

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

#29

Post by didgetmaster »

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 think many programmers have used file splitting technology at the application level for decades. I know I wrote one for a backup utility (Drive Image) back in the 90s that would split the output files into smaller pieces for transfer to removable media (floppies, Zip drives, CDs, DVDs, etc.).

It sounds like BigFat is an extension that takes away the need to do this at the application level. The code does all the splitting and merging for you so you can write a program that acts like the file is on a file system that supports files > 4GB.

Post reply on HN