Sources
Help build the largest human-edited directory on the web.
Submit a site - Become an editor
Wikipedia. Licensed under the GNU Free Documentation License.
Are you an expert in this subject? Join the discussion and share your knowledge at Wikipedia.org.
Journaling file system
From Wikipedia, the free encyclopedia
A journaling file system is a file system that logs changes to a journal (usually a circular log in a specially-allocated area) before actually writing them to the main file system. Such file systems are less likely to become corrupted in the event of power failure or system crash.
Contents |
File systems tend to be very large data structures; updating them to reflect changes to files and directories usually requires many separate write operations. This introduces a race condition, in which an interruption (like a power failure or system crash) can leave data structures in an invalid intermediate state.
For example, deleting a file on a Unix file system involves two steps:
- Removing its directory entry.
- Marking space for the file and its inode as free in the free space map.
If step 1 occurs just before a crash, there will be an orphaned inode and hence a storage leak. On the other hand, if only step 2 is performed first before the crash, the not-yet-deleted file will be marked free and possibly be overwritten by something else.
Recovery in a non-journaled file system requires a complete walk of its data structures to find and correct any inconsistencies. This can be slow if the file system is large, and there is little available I/O bandwidth.
A journaled file system maintains a journal of the changes it intends to make, ahead of time. After a crash, recovery simply involves replaying changes in the journal until the file system is consistent again. The changes are thus said to be atomic (or indivisible) in that they either:
- succeed (have succeeded originally or be replayed completely during recovery), or
- are not replayed at all.
Some file systems allow the journal to grow, shrink and be re-allocated just as would a regular file; most, however, put the journal in a contiguous area or a special hidden file that is guaranteed not to move or change size while the file system is mounted.
A physical journal logs verbatim copies of blocks that will be written later, such as ext3.[1] A logical journal logs information about the changes in a special, compact format, such as XFS. This reduces the amount of data that needs to be read from and written to the journal in large, metadata-heavy operations (for example, deleting a large directory tree).
Some UFS implementations avoid journaling and instead implement soft updates: they order their writes in such a way the on-disk file system is never inconsistent, or inconsistent only in cases of storage leaks. To recover from these leaks, the free space map is reconciled against a full walk of the file system at next mount. This garbage collection is usually done in the background.[2]
Journaling can have a severe impact on performance because it requires that all data be written twice.[3] Metadata-only journaling is a compromise between reliability and performance that stores only changes to file metadata in the journal. This still ensures that the file system can recover quickly when next mounted, but leaves an opportunity for data corruption because unjournaled file data and journaled metadata can fall out of sync.
For example, appending to a file on a Unix file system involves three steps:
- Increasing the size of the file in its inode.
- Allocating space for the extension in the free space map.
- Writing the appended data to the newly-allocated space.
In a metadata-only journal, step 3 would not be logged. If step 3 was not done, but steps 1 and 2 are replayed during recovery, the file will be appended with garbage.
The write cache in most operating systems sorts its writes (with elevator sort or some similar scheme) to maximize throughput. To avoid an out-of-order write hazard with a metadata-only journal, writes for file data must be sorted so that they are committed to storage before their associated metadata. This can be tricky to implement because it requires coordination within the operating system kernel between the file system driver and write cache. An out-of-order write hazard can also exist if the underlying storage:
- cannot write blocks atomically, or
- re-sorted its writes, or
- does not honor requests to flush its write cache.
In log-structured file systems, write-twice penalty does not apply because the journal itself is the file system. Most Unix file systems are not log-structured, but some implement similar techniques in order to avoid the double-write penalty. In particular, Reiser4 can group many separate writes into a single contiguously-written chunk, then extend the head of the journal to enclose the newly-written chunk. The tail of the journal retracts from the chunk after it has been committed to storage.[4]
- ^ Tweedie, Stephen C (1998), "Journaling the Linux ext2fs Filesystem", The Fourth Annual Linux Expo, <http://donner.cs.uni-magdeburg.de/bs/lehre/wise0001/bs2/journaling/journal-design.pdf>.
- ^ Seltzer, Margo I; Ganger, Gregory R & McKusick, M Kirk, ""Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems"", 2000 USENIX Annual Technical Conference (USENIX Association), <http://www.usenix.org/event/usenix2000/general/full_papers/seltzer/seltzer_html>.
- ^ Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C & Arpaci-Dusseau, Remzi H, "Analysis and Evolution of Journaling File Systems", 2005 USENIX Annual Technical Conference (USENIX Association), <https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf>.
- ^ Reiser, Hans (October 2003), Reiser4 white paper, <http://namesys.com/v4/v4.html>. Retrieved on 27 July 2007.