Editing Ext3 (section)

==Advantages==
The speed performance of ext3 is less attractive than competing Linux filesystems, such as ext4, [[JFS (file system)|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. Benchmarks suggest that ext3 also uses less CPU power than ReiserFS and XFS.<ref>{{cite journal |first=Justin|last=Piszcz |title=Benchmarking Filesystems Part II |journal=Linux Gazette |issue=122 |url=http://linuxgazette.net/122/TWDT.html#piszcz }}</ref><ref>{{cite journal |first=Hans |last=Ivers |title=Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch |url=http://www.debian-administration.org/articles/388 |journal= |access-date=2010-11-03 |archive-date=2008-09-13 |archive-url=https://web.archive.org/web/20080913112251/http://www.debian-administration.org/articles/388 |url-status=dead }}</ref> It is also considered safer than the other Linux file systems, due to its relative simplicity and wider testing base.<ref>{{cite web|first=Roderick W. |last=Smith |date=2003-10-09 |title=Introduction to Linux filesystems and files |publisher=Linux.com |url=http://www.linux.com/archive/feature/31939 |archive-url=https://web.archive.org/web/20110830122414/http://www.linux.com/archive/feature/31939 |archive-date=August 30, 2011 }}</ref><ref>{{cite web |date=2010-04-23 |first=James|last=Trageser |title=Which Linux filesystem to choose for your PC? Ext2, Ext3, Ext4, ReiserFS (Reiser3), Reiser4, XFS, Btrfs |url=http://linuxtweaks.wordpress.com/2010/04/23/which-linux-filesystem-to-choose/ }}</ref>

ext3 adds the following features to ext2:
* A [[Journaling file system|journal]]
* Online file system growth
* [[HTree]] indexing for larger directories<ref>{{cite web|url=http://ext2.sourceforge.net/2005-ols/paper-html/node3.html|title=Directory indexing|first=Mingming|last=Cao|work=Features found in Linux 2.6|access-date=2009-04-01|archive-date=2019-07-18|archive-url=https://web.archive.org/web/20190718230754/http://ext2.sourceforge.net/2005-ols/paper-html/node3.html|url-status=dead}}</ref>

Without these features, any ext3 file system is also a valid ext2 file system. This situation 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 an [[fsck]] tool. The close relationship also makes conversion between the two file systems (both forward to ext3 and backward to ext2) straightforward.

ext3 lacks "modern" filesystem features, such as dynamic [[inode]] allocation and [[extents]]. This situation might sometimes be a disadvantage, but for recoverability, it is a significant advantage. The file system metadata is all in fixed, well-known locations, and data structures have some redundancy. In significant data corruption, ext2 or ext3 may be recoverable, while a tree-based file system may not.

===Size limits===
The maximum number of [[Block (data storage)|blocks]] for ext3 is 2<sup>32</sup>. The size of a block can vary, affecting the maximum number of files and the maximum size of the file system:<ref>{{cite web|url=http://lxr.linux.no/linux+v2.6.29/Documentation/filesystems/ext2.txt|title=Documentation/filesystems/ext2.txt|author=Matthew Wilcox|work=Linux kernel source documentation}}</ref>

{| class="wikitable"
|-
! Block size
! Maximum<br>file size
! Maximum<br>file-system size
|-
| 1 [[Kibibyte|KiB]]
| 16 [[Gibibyte|GiB]]
| 2 [[Tebibyte|TiB]]
|-
| 2 KiB
| 256 GiB
| 8 TiB
|-
| 4 KiB
| 2 TiB
| 16 TiB
|-
| 8 KiB<ref group=limits>In Linux, 8&nbsp;KiB block size is only available on architectures which allow 8&nbsp;KiB [[paging|pages]], such as [[DEC Alpha|Alpha]].</ref>
| 2 TiB
| 32 TiB
|}

<references group="limits" />

===Journaling levels===
There are three levels of [[Journaling file system|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, if the journal has enough space. 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 filesystem.<ref name=devworks-part8 />

; 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 that the new file or appended data has not been "committed", so it will be purged by the cleanup process. (Thus 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.<ref name=devworks-part8>{{Cite web |url=http://www.ibm.com/developerworks/library/l-fs8.html |title=Common threads: Advanced filesystem implementor's guide, Part 8 |work=IBM developerWorks |author=Daniel Robbins |author-link=Daniel Robbins (computer programmer) |date=2001-12-01 |archive-url=https://web.archive.org/web/20071013213924/http://www.ibm.com/developerworks/linux/library/l-fs8.html |archive-date=2007-10-13 }}</ref><ref>[http://evuraan.blogspot.com/2007/01/speeding-up-ext3-filesystems.html curious onloooker: Speeding up ext3 filesystems]. Evuraan.blogspot.com (2007-01-09). Retrieved on 2013-06-22.</ref>

; 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 unexpectedly after a journal recovery. The lack of synchronization between data and journal is faster in many cases. JFS uses this level of journaling, but ensures that any "garbage" due to unwritten data is zeroed out on reboot. XFS also uses this form of journaling.

In all three modes, the internal structure of file system is assured to be consistent even after a crash. 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.