| |||||||||||||
RFS = FAT + journal? Robust - sigh...RFS = FAT + journal? Robust - sigh...Posted Nov 16, 2009 22:06 UTC (Mon) by nix (subscriber, #2304)In reply to: RFS = FAT + journal? Robust - sigh... by drag Parent article: SamyGO: replacing television firmware
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.)
(Log in to post comments)
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
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.
|
|||||||||||||