The ext3 or third extended file system is a journalled file system that is commonly used by the Linux operating system. It is the default file system for many popular Linux distributions. Stephen Tweedie first revealed that he was working on extending ext2 in a February 1999 kernel mailing list posting and the file system was merged with the mainline kernel from 2.4.15 onward.

Although its performance (speed) is less attractive than competing linux file systems such as JFS, ReiserFS and XFS, it does have the significant advantage that it allows in-place upgrades from the ext2 file system without having to back up and restore data as well as requiring lower CPU consumption than ReiserFS and XFS.

The ext3 file system adds, over its predecessor:

* A journal
* Online file system growth

Without these, any ext3 file system is also a valid ext2 file system. This has allowed well-tested and mature file system maintenance utilities for maintaining and repairing ext2 file systems to also be used with ext3 without major changes. The ext2 and ext3 file systems share the same standard set of utilities, e2fsprogs, which includes a fsck tool. The close relationship also makes conversion between the two file systems (both forward to ext3 and backward to ext2) straightforward.

There are three levels of journaling available in the Linux implementation of ext3:

Journal (lowest risk)
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 loc tran once to the main part of the file system.

Ordered (medium risk)
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 or kernel panic 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. (This appends and new files have the same level of integrity protection as the "journaled" level.) 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 new data never made it to disk completely, and the old data is not stored anywhere). Even worse, the intermediate state might intersperse old and new data, because the order of the write is left up to the disk's hardware.[5] [6]

Writeback (highest risk)
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 unexpected after a journal recovery. The lack of synchronicity between data and journal is faster in many cases. XFS,and JFS use this level of journaling, but ensures that any "garbage" due to unwritten data is zeroed out on reboot.