SD Card RL-FlashFS - Power Loss?

Unfortunately I have a lot of bitter experience with this matter. On our current systems that are still ARM7 based, power failure handling is done by saving critical data to a NAND flash. I can write up to 23[KB] within 25[milliseconds] or so (even that seems to cause rare problems but that might be due to the blocking nature of the interrupt system of the ARM7 - the code is solid). We do have problems with SD card corruption, probably due to some file not being closed on time (remember that the buffers must be flushed) and Keil's arbitrary DMA timeout settings that have caused SD card (even industrial grade) to get completely corrupted thanks to sector 0 failure. My advise? Use anything but FlashFS for time critical logging.

Point well taken, Tamir. Thanks for your reply.

we'll proceed with caution.

is it a bad idea in general to use a FAT file system in a system that very well could expect power loss at any time?

As anyone who has ever used FAT file systems on a regular basis can tell you: yes, it's a bad idea. FAT is widely known to be quite spectacularly bad at surviving spontaneous system shutdowns. DOS and Windows (up to 9x) users have had to run file system checks on a shamefully regular basis because of it. I don't even want to think about what FAT would do to a flash storage medium if that didn't use wear levelling in an abstraction layer between the file system and the raw falsh.

this might be an uninformed question, but is the FlashFS (not FAT) that Keil provides with RL-ARM a somewhat robust file system when it comes to ware leveling, and such?

First of for securing against power failure things should be ensured by detecting power failure and allowing application enough time to save data before power to the SD Card is lost. Also problem with SD Card if it looses power during write can render the whole accessed block invalid (meaning it will not contain the original data any more). So, SD Card can not ensure data validity by itself but it must be ensured by hardware not allowing it to loose power while write is in progress. No file system can ensure with software that SD Card will not fail.
Second there is no problem with SD Card wear leveling as most SD Cards do this by themselves and also FAT knows nothing about wear leveling so SD Card can not use translation layer if it needs to be compatible to FAT. SD Card wear leveling quality depends on manufacturer implementation of wear leveling which can differ for different manufacturers.
BTW SD Card is really NAND Flash + NAND Flash controller which handles wear leveling and SD interface handling.

Problems with FAT can be reduced by precreating fixed-sized files, and write changes in sequence to two different files.

Not requiring any any changes to the FAT chains, greatly improve their reliability. And using own FS code, you can make sure that there is no need to update the meta information, i.e. leaving the update time information unchanged.

The above makes the FAT file system look like a container for a "raw" file system, while still making a PC able to read out the file data.

Obivously, a power loss during writes may still create havoc inside the SD controller depending on what actions it performs for the wear leveling actions. Especially since the FAT file system have one sector size while the raw flash memory may have a completely different subdivision into eraseable sectors and a raw flash write may destroy the flash sector affecting the contents multiple file system sectors or the mapping between raw sectors and addressable regions.

The above makes the FAT file system look like a container for a "raw" file system, while still making a PC able to read out the file data.

Unfortunately, it also makes that file system container almost as unusable for the casual PC user as just forgetting about FAT and just using it as a raw device would have.

I.e. you can't store even a simple text file, must less a GIF image or other data file format, in that file-system-in-a-FAT-file thing without needing a special application that can parse the internal file system and find it. A FAT file system isn't much use if all it ever shows you is a single file, as large as the entire medium, but you've got no idea what's actually supposed to be in there without running the dedicated "decode this" interface program.

You misunderstood me. I never talked about hiding any file system within a single file in the FAT file system.

I talked about storing raw binary data (for example measurements) within a preallocated FAT file of fixed size, to make sure that there are no FAT chains that may break in case of a power loss.

Most image formats don't care if the file in the file system is much larger than the actual image data.

But quite a lot of embedded equipment don't need to store images but need instead to store captured measurements. And in many situations it's ok to have binary files on the memory card that requires a special PC program to extract the data. The PC sees files in a FAT file system, so you don't need to worry about any drivers to extract your "measurements1.dat". And if a power loss results in "measurements1.dat" being broken, you can normally save the day by instead retrieving the "measurements2.dat" file instead.

If you did not have a FAT file system, then your PC would think the memory card was broken or unformatted if you put it in the PC. That is way worse than finding one or more files of fixed size and having a Windows program process the memory card contents into other formats.