Ext3  journaled File system  – A study

 Introduction

  A file system is to represent the particular way that the data is stored and how the operating system keeps track of it. Information such as  who(user/group) created a file, date of creation and last modification, what permissions are granted for reading and modifying the file, the size of the file, and where it is located on the drive or partition, are all part of the responsibility of the file system. In other words files system must manage all the files and all of their metadata.

  How file systems become corrupted

Suppose you created a word processing document. After few days you were adding some data to it. But the system crashes before you save the file, you have lost all your changes but your original file will still be okay. If the machine crashes after you save the file, then you really haven’t lost anything but it takes time to reboot and reload the program. But what happens if the machine crashes during the exact moment when the disk is being written?

Since the new version of the file is physically overwriting all or part of the old version, the data can have some of each at the moment the drive stops writing. You end up with a file that you can’t open because the internal format of its data is inconsistent with what the application expects.

This gets even worse if the drive was writing the metadata areas, such as the directory itself. Now instead of one corrupted file, you have one corrupted file system In other words, you can lose an entire directory or all the data on an entire disk partition.

 Modern systems, such as Linux, OS/2, and NT, do make an attempt to prevent and recover from the metadata corruption. To accomplish this, the system performs an extensive file system analysis during bootup. Well-designed file systems often incorporate redundant copies of critical metadata, so that it is extremely unlikely for that data to be completely lost. The system traces out where the corrupt metadata is, and then either repairs the damage by copying from the redundant version or simply deletes the file or files whose metadata is affected. Losing files this way is bad, but it is much better than losing the whole partition.

Unfortunately, such an extensive diagnostic analysis requires a great deal of time. Even on a very fast PC, a large and heavily-used partition can require several minutes to check. Most of the time, however, the check is not really needed because the system was shut down normally, without a sudden crash. To prevent unnecessary delays, the operating system’s normal shutdown process puts a status flag on the file system as it is unmounted, marking it as a “clean” file system. If a crash happened, the system never has the chance to mark the files ystem as “clean” and the bootup process knows that it needs to run the extensive file system tests just to be safe.

The term “journaled” means that the file system maintains a log or record of what it is doing to the main data areas of the disk, so that if a crash occurs it can re-create anything that was lost.

When the system is about to alter the metadata, it first makes an entry in the journal saying, “Here is what I’m going to change.” Then it makes the change. Finally, it goes back to the journal and either marks that change as “completed” or simply deletes the journal entry entirely.

The idea is that the system can crash at any point in this process but that such a crash won’t have lasting effect. If the crash happens before the first journal entry, then the original data is still on the disk. You lost your new changes, but you didn’t lose the file in its previous state. If the crash happens during the actual disk update, you still have the journal entry showing what was supposed to have happened. So when the system reboots, it can simply replay the journal entries and complete the update that was interrupted, or it can back out a partially completed update to restore the file’s previous state. In either case, you have valid data.

 The ext3 file system is a journaling extension to the standard ext2 file system on Linux os. Journaling results in massively reduced time spent recovering a file system after a crash, and is therefore in high demand in environments where high availability is important, not only to improve recovery times on single machines but also to allow a crashed machine’s file system to be recovered on another machine when we have a cluster of nodes with a shared disk.

 Journaling Options are Available with the ext3 file system

The ext3 file system provides three options. These are as follows:

• journal -. Both metadata and file contents are written to the journal before being committed to the main file system. Because the journal is relatively continuous on disk, this can improve performance in some circumstances. In other cases, performance gets worse because the data must be written twice – once to the journal, and once to the main part of the file system. Journals all data requiring greater journal space and reduced performance. The most secure data retention policy
• ordered -  Only metadata is journaled; file contents are not, but it’s guaranteed that file contents are written to disk before associated metadata is marked as committed in the journal. This is the default on many Linux distributions. If there is a power outage while a file is being written or appended to, the journal will indicate the new file or appended data has not been “committed”, so it will be purged by the cleanup process. However, files being overwritten can be corrupted because the original version of the file is not stored. Thus it’s possible to end up with a file in an intermediate state between new and old, without enough information to restore either one or the other. The intermediate state might intersperse old and new data, because the order of the write is left up to the disk’s hardware.
•  writeback – Only metadata is journaled; file contents are not. The contents might be written before or after the journal is updated. As a result, files modified right before a crash can become corrupted. For example, a file being appended to may be marked in the journal as being larger than it actually is, causing garbage at the end. Older versions of files could also appear unexpectedly after a journal recovery. The lack of synchronization between data and journal is faster in many cases. It has greater speed at the price of limited data integrity. So allows old data to show up in files after a crash and relies on kernel’s standard writebacks to flush buffers.

Interested to share and acquire knowledge.

Article Source:http://www.articlesbase.com/operating-systems-articles/ext3-journaled-file-system-a-study-1652326.html