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

91–100 of 109 posts

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

#91

Post by babypuncher »

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…

None of those features you mention mean anything in the situations where FAT is still being used.

FAT is still popular because it is very easy to implement, and anything can read and write to it. It is pretty easy to implement the file system on a low power microcontroller and have it write data to an SD card. Your users can then plug that SD card into any computer and view the data, or add to it.

Using btrfs in a situation like this means a lot more coding on your end, and your users lose the convenience of the SD card using a file system they can easily interact with.

Nobody is using FAT for their primary system partition. It is almost exclusively relegated to embedded systems and small external storage devices where broad compatibility is an important feature.

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

#92

Post by babypuncher »

chasil wrote: post #48
guipsp wrote: post #45

Earlier quoted context omitted.

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

All of those patents expired a long time ago

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

#93

Post by babypuncher »

teknopaul wrote: post #87
guipsp wrote: post #51

Earlier quoted context omitted.

Microsoft isn't getting a check from me using FAT32.

Hmm that's like saying Google is free.

Not at all, seeing as all FAT32 related patents expired many years ago

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

#94

Post by babypuncher »

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…

exFAT is a good candidate for a replacement "lowest common denominator" file system, and support for it is growing rapidly now that Microsoft has effectively open-sourced it.

But as you pointed out, in a transitionary period there is still a need to support older devices and software. FOSS purists may also not approve of using exFAT in some situations, since the relevant patents have not yet expired, even if MS has released them to the OIN.

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

#95

Post by DannyBee »

mort96 wrote: post #81
DannyBee wrote: post #70

Earlier quoted context omitted.

It's as backwards compatible as any other fat extension done so far. For example, LFN fails if you create too many files with the same first 6 letters :) I'm actually honestly not sure why representing all legal FAT32 file structures is a particularly useful goal? FAT in particular, in all of it's forms, has always had limitations and weirdness in filenames, etc.

I don't understand your LFN example. Which FAT file structure can be represented with LFN disabled that's no longer possible to represent if you add support for LFN? If BigFAT was actually backwards compatible, it would've been a no-brainer to add support for in filesystem drivers. But since it changes the interpretation of some legitimate structures, adding support for BigFAT is a breaking change. I don't know wheth…

Err, a directory with all possible six character prefixes, differentiated at the seventh character, is representable without LFN but not with it. Wikipedia actually has links/info on it if you want more.

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

#97

Post by tenebrisalietum »

scohesc wrote: post #49

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.

A filesystem translates a filename-based streaming I/O API to the way a disk talks, which is "Read/write 512 times X bytes of data at disk block N."

The I/O API or "commands" are the same; different filesystems will implement it differently.

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

#98

Post by selfhoster11 »

Tijdreiziger wrote: post #71
selfhoster11 wrote: post #62

Earlier quoted context omitted.

BtrFS is unsafe for production use unless it's coupled with really good backups. On the other hand, NTFS on Windows, Ext* on Linux, or ZFS on any supported OS, has not been known to eat data as frequently.

Synology uses Btrfs + mdadm RAID for their NAS boxes, which are regarded as rock-solid. https://www.synology.com/en-global/dsm/Btrfs

Whatever voodoo they are pulling out of thin air, is clearly not present on commodity, non-tuned Btrfs filesystems. That, and most people have backups set up on their NAS.

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

#99

Post by RealStickman_ »

mort96 wrote: post #18
prmoustache wrote: post #16

Earlier quoted context omitted.

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.

In my opinion UDF [1] would be a great option. Although it's mainly used in DVDs, it can also be created as read/write capable. [2]

[1] https://en.m.wikipedia.org/wiki/Universal_Disk_Format

[2] https://duncanlock.net/blog/2013/05/13/using-udf-as-an-impro...

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

#100

Post by saurik »

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…

I imagine the premise is that if you mount this disk in an implementation that doesn't understand these structures it works and you don't corrupt it, making the format backwards compatible with old implementations. This is similar to the trick used to add long filenames: putting a special 8.3 file with a ~ that includes the full file name.
Post reply on HN