Journalling File System
| Depends on | Filing System Implementation • Security |
|---|
When doing some-set-of-operations in computing, not infrequently things which are logically simultaneous need to be done in sequence. Various examples appear … and probably more frequently in operating systems’ code than in general applications.
Updating a file is one example, especially if you allow for the possibility of faults, crashes and someone disconnecting the power half-way through.
Such problems are likely to occur most frequently in embedded systems, which often operate in reasonably hostile environments. These may also be systems where reliability is important: remember that computers are flying aeroplanes…
Without delving into significant detail it is possible to take actions which significantly help to improve reliability and recoverability.
For example, when ‘rewriting’ an existing file it can make sense to create a new (temporary) file instead. Only when it is certain that the update is complete (and, possibly, verified) is a ‘switch’ made and the ‘new’ file becomes ‘the’ file. The likelihood of a problem occurring at that moment is much less than the likelihood of a problem over the (prolonged?) period of file writing. Any problems and the previous version can be recovered intact. This is another place where the ordering of the sequence of operations is important.
This sort of operation can be important when the (part of the?) file system is, for example, in Flash memory where whole areas of the memory have to be erased before rewriting can start. Flash memory is used in ‘Thumb drives’, Tablets, ’phones, cameras … just about all portable computer equipment these days.
You might like to think of similar examples where a ‘commit’ needs to be an ‘all or nothing’ action for reliability: for example in database transactions, version control systems …
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 14.7.2, pages 587-588 |
|---|
