ext3

It used to be the default file system for many popular Linux distributions but generally has been supplanted by its successor version ext4.

[3] The main advantage of ext3 over its predecessor, ext2, is journaling, which improves reliability and eliminates the need to check the file system after an improper, a.k.a.

Stephen Tweedie first revealed that he was working on extending ext2 in Journaling the Linux ext2fs Filesystem in a 1998 paper, and later in a February 1999 kernel mailing list posting.

[4][5][6] The speed performance of ext3 is less attractive than competing Linux filesystems, such as ext4, JFS, ReiserFS, and XFS, but ext3 has a significant advantage in that it allows in-place upgrades from ext2 without having to back up and restore data.

[7][8] It is also considered safer than the other Linux file systems, due to its relative simplicity and wider testing base.

The ext2 and ext3 file systems share the same standard set of utilities, e2fsprogs, which includes an fsck tool.

In any case, only the data content of files or directories which were being modified when the system crashed will be affected; the rest will be intact after recovery.

[23][24] Consequently, ext4 (the successor to ext3) has an online filesystem defragmentation utility e4defrag[25] and currently supports extents (contiguous file regions).

Unlike a number of modern file systems, ext3 does not have native support for snapshots, the ability to quickly capture the state of the filesystem at arbitrary times.

The Next3 file system is a modified version of ext3 which offers snapshots support, yet retains compatibility with the ext3 on-disk format.

[35] Filesystems going through the device mapper interface (including software RAID and LVM implementations) may not support barriers, and will issue a warning if that mount option is used.

[36][37] There are also some disks that do not properly implement the write cache flushing extension necessary for barriers to work, which causes a similar warning.

[39] There is also a potential issue with the barrier implementation related to error handling during events, such as a drive failure.

[40] It is also known that sometimes some virtualization technologies do not properly forward fsync or flush commands to the underlying devices (files, volumes, disk) from a guest operating system.

[41] Similarly, some hard disks or controllers implement cache flushing incorrectly or not at all, but still advertise that it is supported, and do not return any error when it is used.