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

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.