View source for Ext3

{{Short description|Journaling file system for Linux}}
{{For|the gene|EXT3 (gene)}}
{{lowercase|title=ext3}}
{{Infobox Filesystem
| name                    = ext3
| full_name               = Third extended file system
| preceded by = [[ext2]]
| succeeded by = [[ext4]]
| developer               = [[Stephen Tweedie]]
| introduction_os         = [[Linux kernel|Linux]] 2.4.15
| introduction_date       = November 2001
| preceded_by             = [[ext2]]
| succeeded_by            = [[ext4]]
| partition_id            = 0x83 ([[Master boot record|MBR]]) <br> [[Basic Data Partition|EBD0A0A2-B9E5-4433-87C0-68B6B72699C7]] ([[GUID Partition Table|GPT]])
| directory_struct        = Table, hashed [[B-tree]] with dir_index enabled
| file_struct             = bitmap (free space), table (metadata)
| bad_blocks_struct       = Table
| max_filename_size       = 255 bytes
| max_files_no            = Variable, allocated at creation time<ref>The maximum number of inodes (and hence the maximum number of files and directories) is set when the file system is created. If ''V'' is the volume size in bytes, then the default number of inodes is given by ''V''/2<sup>13</sup> (or the number of blocks, whichever is less), and the minimum by ''V''/2<sup>23</sup>. The default was deemed sufficient for most applications. The max number of subdirectories in one directory is fixed to 32000.</ref>
| max_volume_size         = 4 [[tebibyte|TiB]] – 32 [[tebibyte|TiB]]
| max_file_size           = 16 [[gibibyte|GiB]] – 2 [[tebibyte|TiB]]
| filename_character_set  = All bytes except [[Null character|NUL]] ('\0') and '/'
| dates_recorded          = modification (mtime), attribute modification (ctime), access (atime)
| date_range              = December 14, 1901 – January 18, 2038
| date_resolution         = 1&nbsp;s
| forks_streams           =
| attributes              = allow-undelete, append-only, h-tree (directory), immutable, journal, no-atime, no-dump, secure-delete, synchronous-write, top (directory)
| file_system_permissions = Unix permissions, [[Access-control_list#POSIX_ACL|POSIX ACLs]] and arbitrary security attributes (Linux 2.6 and later)
| compression             = No
| encryption              = No (provided at the block device level)
| single_instance_storage = No
| OS                      = [[Linux]], [[BSD]], [[ReactOS]],<ref>{{cite web|url=https://reactos.org/project-news/reactos-042-released|title=ReactOS 0.4.2 Released|work=reactos.org|access-date=17 August 2016}}</ref> [[Microsoft Windows|Windows]] (through an [[Installable File System|IFS]])
}}

'''ext3''', or '''third extended filesystem''', is a [[journaling file system|journaled file system]] that is commonly used with the [[Linux kernel]]. It used to be the default [[file system]] for many popular [[Linux distributions]] but generally has been supplanted by its successor version [[ext4]].<ref name=":0">{{Cite web|url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-ext4.html|title = Chapter 6. The Ext4 File System Red Hat Enterprise Linux 6}}</ref> The main advantage of ext3 over its predecessor, [[ext2]], is [[journaling file system|journaling]], which improves reliability and eliminates the need to check the file system after an unclean or improper [[Shutdown (computing)|shutdown]]. 

==History==

[[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. The filesystem was merged with the mainline Linux kernel in November 2001 from 2.4.15 onward.<ref name=":1">{{cite journal | author = Stephen C. Tweedie | url = https://e2fsprogs.sourceforge.net/journal-design.pdf | title = Journaling the Linux ext2fs Filesystem | journal = Proceedings of the 4th Annual LinuxExpo, Durham, NC |date=May 1998 | access-date=2007-06-23}}</ref><ref>{{cite web | url=http://marc.info/?l=linux-kernel&m=91926557602501&w=2 | title=Re: fsync on large files | author=Stephen C. Tweedie | date=February 17, 1999 | work=Linux kernel mailing list}}</ref><ref>{{cite web | url=http://marc.info/?l=linux-kernel&m=100650331813822&w=2 | title=2.4.15-final | author=Rob Radez | date=November 23, 2001 | work=Linux kernel mailing list}}</ref> 

==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=https://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>[https://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.

==Disadvantages==

===Functionality===
Because ext3 aims to be [[Backward compatibility|backward-compatible]] with the earlier ext2, many of the on-disk structures are similar to those of ext2. Consequently, ext3 lacks recent features, such as [[Extent (file systems)|extents]], dynamic allocation of [[inode]]s, and [[block sub-allocation]].<ref>{{cite web | url=https://ext2.sourceforge.net/2005-ols/paper-html/node18.html | title=Extents, Delayed Allocation | first=Rob | last=Radez | year=2005 | work=future of ext3 | access-date=2008-07-30 | archive-date=2008-07-08 | archive-url=https://web.archive.org/web/20080708205131/http://ext2.sourceforge.net/2005-ols/paper-html/node18.html | url-status=dead }}</ref> A directory can have at most 31998 ''subdirectories'', because an inode can have at most 32,000 links (each direct subdirectory increases their parent folder inode link counter in the ".." reference).<ref>Robert Nichols (2007-04-03) [http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2007-04/msg00153.html Re: How many sub-directories ?] {{Webarchive|url=https://web.archive.org/web/20081006043647/http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2007-04/msg00153.html |date=2008-10-06 }} linux.derkeiler.com</ref>

On ext3, like for most current Linux filesystems, the system tool "[[fsck]]" should not be used while the filesystem is mounted for writing.<ref name=":0" /> Attempting to check a filesystem that is already mounted in read/write mode will (very likely) detect inconsistencies in the filesystem metadata. Where filesystem metadata is changing, and fsck applies changes in an attempt to bring the "inconsistent" metadata into a "consistent" state, the attempt to "fix" the inconsistencies will corrupt the filesystem.

===Defragmentation===

{{Update section|date=January 2020}}

There is no online ext3 [[defragmentation]] tool that works on the filesystem level. There is an offline ext2 defragmenter, <code>e2defrag</code>. However, <code>e2defrag</code> may destroy data, depending on the feature bits turned on in the filesystem; it does not know how to handle many of the newer ext3 features.<ref>{{cite web|url=http://marc.info/?l=ext3-users&m=116231468911590&w=2|title=Post to the ext3-users mailing list|author=Andreas Dilger|work=ext3-users mailing list post}}</ref>

There are userspace defragmentation tools, like Shake<ref>[http://vleu.net/shake/ Shake]. Vleu.net. Retrieved on 2013-06-22.</ref> and defrag.<ref>[http://ck.kolivas.org/apps/defrag/ Defrag written in shell]. Ck.kolivas.org (2012-08-19). Retrieved on 2013-06-22.</ref><ref>[http://bazaar.launchpad.net/~jdong/pyfragtools/trunk/files Defrag written in Python]. Bazaar.launchpad.net. Retrieved on 2013-06-22.</ref> Shake works by allocating space for the whole file as one operation, which will generally cause the allocator to find contiguous disk space. If there are files which are used at the same time, Shake will try to write them next to one another. Defrag works by copying each file over itself. However, this strategy works only if the file system has enough free space. A true defragmentation tool does not exist for ext3.<ref>[http://www.redhat.com/archives/ext3-users/2005-March/msg00013.html RE: searching for ext3 defrag/file move program]. Redhat.com (2005-03-04). Retrieved on 2013-06-22.</ref>

However, as the Linux System Administrator Guide states, "Modern Linux filesystem(s) keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system."<ref>[http://www.tldp.org/LDP/sag/html/filesystems.html 5.10. Filesystems]. Tldp.org (2002-11-09). Retrieved on 2013-06-22.</ref>

While ext3 is resistant to file fragmentation, ext3 can get fragmented over time or for specific usage patterns, like slowly writing large files.<ref>{{cite web|url=http://trac.transmissionbt.com/ticket/849 |quote=The default Ubuntu filesystem ("ext3") will fragment large (>1GB), slowly growing files (<1&nbsp;MB/s)| title=#849 closed Enhancement (fixed) - preallocation to prevent fragmentation |work=trac.transmissionbt.com}}</ref><ref>{{cite web|quote=We found heavily fragmented free areas on an intensively used IMAP server which stores all its emails in individual files – although more than 900&nbsp;GB of the total disk space of 1.4&nbsp;TB were still available|url= http://www.heise-online.co.uk/open/Tuning-the-Linux-file-system-Ext3--/features/110398/3|date=27 October 2008|author=Oliver Diedrich|title=Tuning the Linux file system Ext3}}</ref> Consequently, ext4 (the successor to ext3) has an online filesystem defragmentation utility e4defrag<ref>[http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0 Ext4 – Linux Kernel Newbies]. Kernelnewbies.org (2011-05-19). Retrieved on 2013-06-22.</ref> and currently supports [[extent (file systems)|extents]] (contiguous file regions).

===Undelete===

ext3 does not support the recovery of deleted files. The ext3 driver actively deletes files by wiping file inodes<ref>[http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html Linux ext3 FAQ]. Batleth.sapienti-sat.org. Retrieved on 2013-06-22.</ref> for crash safety reasons.

There are still several techniques<ref>[http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html HOWTO recover deleted files on an ext3 file system] {{webarchive|url=https://web.archive.org/web/20100919000253/http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html |date=2010-09-19 }}. Xs4all.nl (2008-02-07). Retrieved on 2013-06-22.</ref> and some free<ref>[http://www.cgsecurity.org/wiki/PhotoRec PhotoRec – GPL'd File Recovery]. Cgsecurity.org. Retrieved on 2013-06-22.</ref> and proprietary<ref>[http://www.ufsexplorer.com/download_stdr.php UFS Explorer Standard Recovery version 4]. Ufsexplorer.com. Retrieved on 2013-06-22.</ref> software for recovery of deleted or lost files using file system journal analysis; however, they do not guarantee any specific file recovery.

===Compression===
e3compr<ref>[[SourceForge:projects/e3compr/|e3compr – ext3 compression]]. Sourceforge.net. Retrieved on 2013-06-22.</ref> is an [[unofficial patch]] for ext3 that does transparent [[data compression|compression]]. It is a direct port of e2compr and still needs further development. It compiles and boots well with upstream kernels{{Citation needed|date=December 2008}}, but journaling is not implemented yet.

===Lack of snapshots support===
Unlike a number of modern file systems, ext3 does not have native support for [[Snapshot (computer storage)|snapshots]], the ability to quickly capture the state of the filesystem at arbitrary times. Instead, it relies on less-space-efficient, volume-level snapshots provided by the Linux [[Logical Volume Manager (Linux)|LVM]]. The [[Next3]] file system is a modified version of ext3 which offers snapshots support, yet retains compatibility with the ext3 on-disk format.<ref name="next3">{{cite web|author=Jonathan Corbet|title=The Next3 filesystem|url=https://lwn.net/Articles/387231/|publisher=LWN}}</ref>

===No checksumming in journal===
ext3 does not do [[checksum]]ming when writing to the journal. On a storage device with extra cache, if ''barrier=1'' is not enabled as a mount option (in [[/etc/fstab]]), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.<ref name="archives.free">[http://archives.free.net.ph/message/20070518.134838.52e26369.en.html Re: Frequent metadata corruption with ext3 + hard power-off] {{Webarchive|url=https://web.archive.org/web/20070928031902/http://archives.free.net.ph/message/20070518.134838.52e26369.en.html |date=2007-09-28 }}. Archives.free.net.ph. Retrieved on 2013-06-22.</ref><ref>[http://archives.free.net.ph/message/20070519.014256.ac3a2e07.en.html Re: Frequent metadata corruption with ext3 + hard power-off] {{Webarchive|url=https://web.archive.org/web/20070928031908/http://archives.free.net.ph/message/20070519.014256.ac3a2e07.en.html |date=2007-09-28 }}. Archives.free.net.ph. Retrieved on 2013-06-22.</ref><ref>Red Hat Enterprise Linux, [https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarr.html ''Chapter 20. Write Barriers'']</ref> This is because storage devices with write caches report to the system that the data has been completely written, even if it was written to the (volatile) cache.

If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to [[amortized analysis|amortize]] write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or unrecoverable crash should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the "winners" (transactions with a commit block, including the invalid transaction above, which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. If checksums had been used, where the blocks of the "fake winner" transaction were tagged with a mutual checksum, the file system could have known better and not replayed the corrupt data onto the disk. Journal checksumming has been added to ext4.<ref>[http://article.gmane.org/gmane.linux.file-systems/21373 ext4: Add the journal checksum feature]. Article.gmane.org (2008-02-26). Retrieved on 2013-06-22.</ref>

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.<ref>[http://oss.sgi.com/archives/xfs/2007-12/msg00080.html Re: write barrier over device mapper supported or not?] {{Webarchive|url=https://web.archive.org/web/20090504120507/http://oss.sgi.com/archives/xfs/2007-12/msg00080.html |date=2009-05-04 }}. Oss.sgi.com. Retrieved on 2013-06-22.</ref><ref>[http://madduck.net/blog/2006.08.11:xfs-zeroes/ XFS and zeroed files] {{Webarchive|url=https://web.archive.org/web/20080430221349/http://madduck.net/blog/2006.08.11:xfs-zeroes/ |date=2008-04-30 }}. Madduck.net (2008-07-11). Retrieved on 2013-06-22.</ref> 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.<ref>[https://web.archive.org/web/20110727154012/http://forums.opensuse.org/archives/sls-archives/suse-linux/desktop-environments/379681-barrier-sync.html Barrier Sync]. forums.opensuse.org (March 2007)</ref> In these situations, where barriers are not supported or practical, reliable write ordering is possible by turning off the disk's write cache and using the {{code|1=data=journal}} mount option.<ref name="archives.free" /> Turning off the disk's write cache may be required even when barriers are available.

Applications like databases expect a call to [[sync (Unix)|fsync()]] to flush pending writes to disk, and the barrier implementation doesn't always clear the drive's write cache in response to that call.<ref>[http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg272253.html Re: Proposal for "proper" durable fsync() and fdatasync()]. Mail-archive.com (2008-02-26). Retrieved on 2013-06-22.</ref> There is also a potential issue with the barrier implementation related to error handling during events, such as a drive failure.<ref>[http://www.mjmwired.net/kernel/Documentation/block/barrier.txt I/O Barriers, as of kernel version 2.6.31]. Mjmwired.net. Retrieved on 2013-06-22.</ref> 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.<ref>[http://www.mysqlperformanceblog.com/2011/03/21/virtualization-and-io-modes-extra-complexity/ Virtualization and IO Modes = Extra Complexity]. Mysqlperformanceblog.com (2011-03-21). Retrieved on 2013-06-22.</ref> 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.<ref>[http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transactions/ SSD, XFS, LVM, fsync, write cache, barrier and lost transactions]. Mysqlperformanceblog.com (2009-03-02). Retrieved on 2013-06-22.</ref> There are so many ways to handle fsync and write cache handling incorrectly, it is safer to assume that cache flushing does not work unless it is explicitly tested, regardless of how reliable individual components are believed to be.

===Near-time extinction due to date-stamp limitation===
Ext3 stores dates as [[Unix time]] using four bytes in the file header. 32 bits does not give enough scope to continue processing files beyond January 18, 2038 - the [[Year 2038 problem]].<ref>{{Cite web |last=Clark |first=Libby |title=10 Highlights of Jon Corbet's Linux Kernel Report |date=19 February 2015 |url=https://www.linux.com/blog/10-highlights-jon-corbets-linux-kernel-report |access-date=2019-01-26}}{{cbignore|bot=medic}}</ref>

==ext4==
[[File:E2fsck-uninit.svg|400px|right|thumb|[[fsck]] time dependence on inode count (ext3 vs. ext4)]]
{{Main article|ext4}}
On June 28, 2006, [[Theodore Ts'o]], the principal developer of ext3,<ref>[https://lkml.org/lkml/2006/6/28/454 "Theodore Ts'o": Proposal and plan for ext2/3 future development work]. LKML. Retrieved on 2013-06-22.</ref> announced an enhanced version, called ext4. On October 11, 2008, the patches that mark ext4 as stable code were merged in the Linux 2.6.28 source code repositories, marking the end of the development phase and recommending its adoption.
In 2008, Ts'o stated that although ext4 has improved features such as being much faster than ext3, it is not a major advancement, it uses old technology, and is a stop-gap; Ts'o believes that [[Btrfs]] is the better direction, because "it offers improvements in scalability, reliability, and ease of management".<ref>{{cite web
 | url = https://arstechnica.com/open-source/news/2009/04/linux-collaboration-summit-the-kernel-panel.ars
 | title = Panelists ponder the kernel at Linux Collaboration Summit
 | author= Ryan Paul
 | date = 2009-04-13
 | access-date = 2009-08-22
 | website = Ars Technica
}}</ref> Btrfs also has "a number of the same design ideas that [[ReiserFS|reiser3]]/[[Reiser4|4]] had".<ref>{{cite mailing list
 | title = Re: reiser4 for 2.6.27-rc1
 | author = Theodore Ts'o
 | url = https://lkml.org/lkml/2008/8/1/217
 | date = 2008-08-01
 | access-date = 2010-12-31
 | mailing-list = linux-kernel
}}</ref>

==See also==
* [[List of file systems]]
* [[Comparison of file systems]]
* [[Extended file attributes]]
* [[Ext2Fsd]]
* [[Next3]], modified version of ext3 which snapshots

==References==
{{Reflist|30em}}

==External links==
* {{cite web
 | url   = http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
 | title = Linux ext3 FAQ
 }} as of 2004-10-14.
*[http://www.ibm.com/developerworks/linux/library/l-fs7/ Introducing ext3 – IBM developerWorks Advanced filesystem implementor's guide, Part 7]
*[http://www.paragon-software.com/de/downloads/free_downloads/home.html Paragon ExtBrowser] {{Webarchive|url=https://web.archive.org/web/20100809120607/http://www.paragon-software.com/de/downloads/free_downloads/home.html |date=2010-08-09 }} Free ext2/ext3 Windows driver
*[https://ext2fsd.sourceforge.net/ Ext2 File System For Windows] GPL ext2/ext3 file system driver for Windows 2000/XP/2003/VISTA/2008 (opensource, supports read & write, supports inode of 256 bytes at maximum to access larger disks)
*[http://www.fs-driver.org/ Ext2 Installable File System For Windows] ext2/ext3 file system driver for MS Windows NT4.0/2000/XP/Vista/7/8/8.1/Server 2003/2008/2008 R2/2012/2012 R2 (freeware, closed source, supports read & write, supports inodes of 256 bytes at maximum to access larger disks)
*[https://web.archive.org/web/20080211120420/http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm EXT2 IFS] ext2/ext3 file system driver (read only) for MS Windows NT/2000/XP (opensource), latest version in the web archive
*[http://www.chrysocome.net/explore2fs Explore2fs] An explorer-like GUI tool for accessing ext2/ext3 filesystems under MS Windows
*[http://ext2read.sourceforge.net "Ext2read"] A windows application to read/copy ext2/ext3/ext4 files with extent and LVM2 support.
*[http://www.ufsexplorer.com/download_stdr.php UFS Explorer Standard Recovery version 4] Commercial data recovery and file undelete software for Ext2/Ext3 file systems.
*[https://ext2resize.sourceforge.net/ ext2/ext3 resizing tools]
*[https://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html Presentation on EXT3 Journaling Filesystem] by Dr. Stephen Tweedie at the Ottawa Linux Symposium, 20 July 2000
*[https://ext2.sourceforge.net/2005-ols/paper-html/ State of the Art: Where we are with the Ext3 filesystem] {{Webarchive|url=https://web.archive.org/web/20101231045754/http://ext2.sourceforge.net/2005-ols/paper-html/ |date=2010-12-31 }} by Mingming Cao, Theodore Y. Ts'o, Badari Pulavarty, [[Suparna Bhattacharya]], IBM Linux Technology Center, 2005
*[http://www.howtoadvice.com/Ext3Max/ Tutorial] – Determining Your EXT3 Size Limits
*[https://sourceforge.net/projects/fuse-ext2/ fuse-ext2] An open source ext2/ext3 file system driver for [[Filesystem in Userspace|FUSE]]. (Supports [[Mac OS X]] 10.4 and later ([[Universal Binary]]), using [https://code.google.com/p/macfuse/ MacFuse])
*Windows port of Ext2/Ext4 and other FS in [https://web.archive.org/web/20120111062641/http://www.crossmeta.org/redmine CROSSMETA]
*Red Hat Enterprise Linux, [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-writebarriers.html] ''Chapter 22. Write Barriers''.
*[https://www.theregister.co.uk/2015/02/20/linux_year_2038_problem/ Linux clockpocalypse in 2038 is looming and there's no 'serious plan']

{{Filesystem}}

[[Category:2001 software]]
[[Category:Disk file systems]]
[[Category:File systems supported by the Linux kernel]]