When properly used, the journaling system provides reliable protection for the file system metadata. To ensure proper operation, though, you should understand certain limitations, and follow the corresponding recommendations. A failure to observe these recommendations could spoil the benefits of using the journaling system and lead to file system corruption.
Journaling and cached FILE access mode
FS_FILE_ACCESS_MODE_CACHED should be avoided on a journaled volume. Using the FS_FILE_ACCESS_MODE_CACHED file access mode prevents the journaling module from effectively ensuring file meta data consistency since it might lead to a mismatch between the file’s size and its allocated storage space, resulting in a waste of storage space.
Journaling and FAT16/32 removable media
The journaling module recovery process is based on the assumption that the file system has not been modified since the failure occurred. Therefore, mounting a journaled volume on a host (including accesses through USB Mass Storage Class) should be avoided as much as possible. If it must be done, you must first make sure that the volume has been cleanly unmounted from the embedded host.
Journaling and FAT12 removable media
It is strongly discouraged to mount a FAT12 journaled volume on another host. It is important to note that, unlike the FAT16 and FAT32 cases, it is not enough to cleanly unmount the volume on the embedded host to ensure proper journaling module behavior.
Journaling and cache
Since they do not affect disk write operations, read cache (FS_VOL_CACHE_MODE_RD) and write-through cache (FS_VOL_CACHE_WR_THROUGH) can be safely used along with journaling. However, the combination of write-back cache (FS_VOL_CACHE_WR_BACK) and journaling should be avoided at all cost.
Journaling and API level atomicity
While the journaling system does provide top-level FAT layer operation atomicity, it does not necessarily provide API-level operation atomicity. Most of the time, one API-level file system operation will result in a single top-level FAT operation being performed (see How Journaling Works). In that case, the API-level operation is guaranteed to be atomic. For instance, a call to FSEntry_Rename() will result in a single FAT rename operation being performed (assuming that renaming is not cross-volume). Therefore, the API-level rename operation is guaranteed to be atomic. On the other hand, a call to FSFile_Truncate() will likely result in many successive top-level FAT operations being performed. Therefore, the API-level truncate operation is not guaranteed to be atomic. Non atomic API level operations, along with the possible interruption side effects, are listed in the table below.
API level operation | API level function | Possible interruption side effects |
Entry copy |
| The destination file size could end up being less than the source file size. |
File write (data appending) |
| The file size could be changed to any value between the original file size and the new file size. |
File write (data overwriting) |
| If existing data contained in a file is overwritten with new data, data at overwritten locations could end up corrupted. |
File extension |
| The file size could be changed to any value between the original file size and the new file size. Also, unwritten file space could contain uninitialized on-disk data. |
Table 12-1 Non-atomic API level operations
Journaling and device drivers
Data can be lost in case of unexpected reset or power-failure in either the File System Layer or in the Device Driver Layer. Your entire system is fail-safe only if both layers are fail-safe. The journaling add-on makes the file system layer fail-safe. Some of µC/FS’s device drivers are guaranteed to provide fail-safe sector operations. It is the case of the NOR and NAND flash drivers. For other drivers, the fail-safety of the sector operations depends on the underlying hardware.