RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 16:56 UTC (Mon) by drag (guest, #31333)
In reply to: RFS = FAT + journal? Robust - sigh... by pflugstad
Parent article: SamyGO: replacing television firmware

This is actually pretty normal.

Microsoft themselves have 'Transaction Safe' FAT version they offer for
embedded systems running Windows CE 5.x (and probably others). Since people
expect that it's 'ok' to simply pull the power from handheld devices and
such then it's obvious that FAT itself is not really that suitable.
Customers will have a strong tendency to corrupt things after a while. So
transaction safe FAT is designed to deal with that.

It's simply a FAT file system with two file allocation tables. I guess the
goal is to make file system changes a fully atomic event.

And the Linux FAT driver actually works with it, mostly. You can read from
it quite easily, and write. I don't think it's a good idea to use the file
system back in the embedded system after that.. but it's easily to pull the
information off of one.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 19:38 UTC (Mon) by pflugstad (subscriber, #224) [Link] (2 responses)

I know it's normal. That's my main point: what on earth does Samsung think they are gaining by trying to keep their super-duper RFS secret?

It was also to point out that companies need to start understanding that 99% of the stuff their engineers come up with is totally obvious and has been done before (and is even patented in this case), so that they don't end up wasting vast quantities of everyone's time and money on silly crap like the GPL shim layer. Not that the stuff is useless, but come on, a *television* company doing "state of the art" filesystem work. GET REAL...

Pete

PS: I guess it was the Samsung website for RFS that set me off... gawd what a load of marketing drivel...

RFS = FAT + journal? Robust - sigh...

Posted Nov 28, 2009 20:15 UTC (Sat) by efexis (guest, #26355) [Link] (1 responses)

Wow that's a lot of assumptions there, like that things are *ever* that simple. Okay, sometimes things are that simple, but most of the time, when something's screaming "this is so simple why can't they see it?" at you, that's usually a strong sign that it's not and there are other factors you're not considering. As much as there are GPL constraints pulling in one direction, there's a fair chance that there are several other licenses on what they can do with the code pulling them in other directions. For a start, we know it's a VFAT compatible filesystem, and from what we've seen recently with TomTom, Microsoft's ownership of that IP will stand up in court, which means chances are Samsung (or "Flash Software Group") currently have a licensing agreement with MS to allow them to use the code, and who knows whom else they've licensed code or other IP that covers what else they can do with it. Judging by the fact that there's other open source driver downloads on their website for other parts of the system or other products, I'm definitely inclined to believe that it's simply a case of contending licensing issues...

But really, it's a FAT based filesystem that open implementations can still read/write to should the need be there, who cares? Let 'em have their locked away filesystem add-ons, there's so much better out there and on the way.

As far as patenting goes, that covers implementation, if they do their transactional IO differently then it doesn't come under that patent, and if they don't do it different, then the patent holder is probably just someone else who Samsung have a licensing agreement with adding constraints. It's just business.

RFS = FAT + journal? Robust - sigh...

Posted Dec 2, 2009 7:34 UTC (Wed) by tdwebste (guest, #18154) [Link]

>For a start, we know it's a VFAT compatible filesystem,
>and from what we've seen recently with TomTom, Microsoft's
>ownership of that IP will stand up in court

We do NOT know if VFAT would stand up in court. All we know is TomTom and Microsoft were willing to settle out of court.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 22:06 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

It's simply a FAT file system with two file allocation tables.

Er, didn't the FAT filesystem *always* have two file allocation tables? (Or did FAT32 drop one of them? I had switched to Linux everywhere and stopped paying much attention to such sucky filesystems by then.)

RFS = FAT + journal? Robust - sigh...

Posted Nov 19, 2009 12:58 UTC (Thu) by arnd (subscriber, #8866) [Link]

The point where you get transaction safety with FATfs is when each of the two FAT copies resides on exactly one erase block of the underlying flash, and you do all updates as a copy-on-write operation, like:

1. write modified data blocks and directories in previously unused clusters of the file system, without updating the FAT
2. erase the first copy of the FAT
3. write the modified FAT with the new state to the first copy
4. erase the second copy of the FAT
5. write the modified FAT with the new state to the second copy

Upon mounting, you have to detect which copy to use, normally they are identical, and if they are not you should have an out-of-band checksum in the flash that tells you which copy is garbage (unless you have a fatal hardware problem, one of them is guaranteed to be intact) and you overwrite the broken copy with the good one.

It's an extremely simple operation that works exactly because the FAT design is so trivial that it keeps all block allocation data in one place.
If you file sizes are a large multiple of your cluster size (e.g. when storing audio and video data), it's also highly efficient on flash media.
Considering that FAT was designed for 160kb floppy disks without subdirectories, it works extremely well for todays applications.