Live data from Hacker News

BigFAT – Backward compatible FAT extension for unlimited file size

segger.com

11–20 of 109 posts

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

#11

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?

Well, if we view FAT32 + this name convention as a new filesystem, then filesystem drivers could let you transparently operate on files bigger than 4GB (GiB?) and take care of the splitting for you. FAT32 + this convention would essentially become a filesystem which supports files up to around 4TB. You wouldn't have to make the choice between the patent-encumbered exFAT and the open but limited FAT32.

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

#13
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?

It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.

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

#14
>Unfortunately, exFAT has been adopted by the SD Association as the default file system for SDXC cards larger than 32 GB. In our view, this should never have happened, as it forces anyone who wants to access SDXC cards to get a license from Microsoft, basically making this a field owned by Microsoft.

So, this is a bit of a cultural/perception gap between FOSS developers and standards bodies. Most standards bodies have a patent policy of "as long as all the standards-essential patents are licensable for a uniform fee, we're good". Convincing patent holders to not extract royalties from their patents for the sake of easing the lives of FOSS implementers is much, much harder[0].

Microsoft isn't even the only SEP holder for SD, and the standard makes no attempt at being a royalty-free standard. In fact, early SD standards were NDA'd[1] and prohibited FOSS implementation at all.

[0] In fact, so hard that the EU has a conspiracy theory that Google/AOM bullied a patent holder into doing this

[1] Remember, SD cards were basically MMC with primitive DRM

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

#15
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?

I already use FAT32 for some USB sticks when I need to be able to use them on various OSes without having to give it any thought, or for long term archiving.

This would be extremely niche but would have its audience. Heck, I wouldn't be surprised if HN readers adopted it just to taste the thrill of unlimited and obscene power.

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

#16
post #13
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?

It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.

Are the filesystem used on bsd and linux distros patent encumbered? Isn't UFS2 simple enough?

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

#17
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 system from the '80s.

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

#18
post #13

Earlier quoted context omitted.

It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.

Are the filesystem used on bsd and linux distros patent encumbered? Isn't UFS2 simple enough?

UFS2 might be the technically perfect tool for the job, but that doesn't matter when Windows doesn't support it. A camera manufacturer or SD card manufacturer can't start shipping their customers SD cards formatted with UCS2 when it's not supported by Windows. They could start shipping FAT32 SD cards and software and firmware which can read and write FAT32+BigFAT.

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

#19
post #17
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…

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.

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

#20
post #13

Earlier quoted context omitted.

It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.

Are the filesystem used on bsd and linux distros patent encumbered? Isn't UFS2 simple enough?

If you wish for an fs common to both BSD and Linux, ext2fs would be perfect - better than UFS for the job.
Post reply on HN