View source for Ext4

{{Short description|Journaling file system for Linux}}
{{Lowercase title}}
{{Use American English|date=November 2017}}{{Use dmy dates|date=October 2019}}
{{Infobox file system
| name                    = ext4
| full_name               = Fourth extended file system
| developer               = Mingming Cao, Andreas Dilger, Alex Zhuravlev (Tomas), Dave Kleikamp, [[Theodore Ts'o]], Eric Sandeen, Sam Naghshineh, others
| introduction_os         = [[Linux]] 2.6.19
| introduction_date       = 10 October 2006
| preceded_by             = [[ext3]]
| partition_id            = {{mono|0x83}}: [[Master Boot Record|MBR]] / [[Extended Boot Record|EBR]].<br>
{{mono|EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}}: [[GUID Partition Table|GPT]] Windows [[Basic Data Partition|BDP]].<ref name="winbdp">Previously, Linux used the same GUID for the data partitions as Windows (Basic data partition: {{mono|EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}}). Linux never had a separate unique partition type GUID defined for its data partitions. This created problems when dual-booting Linux and Windows in UEFI-GPT setup. The new GUID (Linux filesystem data: {{mono|0FC63DAF-8483-4772-8E79-3D69D8477DE4}}) was defined jointly by GPT fdisk and GNU Parted developers. It is identified as type code {{mono|0x8300}} in GPT fdisk. (See definitions in [http://gptfdisk.git.sourceforge.net/git/gitweb.cgi?p%3Dgptfdisk/gptfdisk;a%3Dblob_plain;f%3Dparttypes.cc;hb%3DHEAD gdisk's parttypes.cc])</ref><br>
{{mono|0FC63DAF-8483-4772-8E79-3D69D8477DE4}}: GPT Linux filesystem data.<ref name="winbdp" /><br>
{{mono|933AC7E1-2EB4-4F13-B844-0E14E2AEF915}}: GPT /home partition.<ref name="DiscoverablePartitionsSpec">{{cite web
 | url        = http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
 | title      = DiscoverablePartitionsSpec
 | website    = freedesktop.org
 | access-date = 7 April 2018}}</ref><br>
{{mono|3B8F8425-20E0-4F3B-907F-1A25A76F98E8}}: [[GUID Partition Table|GPT]] /srv (server data) partition.
| directory_struct        = [[Linked list]], hashed [[B-tree]]
| file_struct             = Extents / Bitmap
| bad_blocks_struct       = Table
| max_filename_size       = 255 bytes (fewer for multibyte [[character encoding]]s such as [[Unicode]])
| max_files_no            = 4 billion (specified at filesystem creation time)
| max_volume_size         = 1 [[exbibyte|EiB]]
| max_file_size           = 16&ndash;256&nbsp;[[Tebibyte|TiB]] (for 4–64&nbsp;[[kibibyte|KiB]] block size)
| filename_character_set  = All characters and character sequences permitted, except for [[Null character|NULL]] ('\0'), '/', and the special file names "." and ".." which are reserved for indicating (respectively) current and parent directories.
| dates_recorded          = modification (mtime), data or attribute modification (ctime), access (atime), delete (dtime), create (crtime)
| date_range              = 14 December 1901 – 10 May 2446<ref name="ext4-timestamp-range">{{cite web
 | title      = ext4: Fix handling of extended tv_sec
 | publisher  = Linux-stable kernel tree
 | url        = https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a4dad1ae24f850410c4e60f22823cba1289b8d52
 | access-date = 2017-02-14}}</ref>
| date_resolution         = Nanosecond
| forks_streams           = No
| attributes              = acl, bh, bsddf, commit=nrsec, data=journal, data=ordered, data=writeback, delalloc, extents, journal_dev, mballoc, minixdf, noacl, nobh, nodelalloc, noextents, nomballoc, nombcache, nouser_xattr, oldalloc, [[Orlov block allocator|orlov]], user_xattr
| file_system_permissions = Unix permissions, [[Access-control list#POSIX ACL|POSIX ACLs]]
| compression             = No
| encryption              = Yes
| single_instance_storage = No 
| license                 = [[GPLv2]]
| OS                      = {{Plainlist|
* [[Linux]]
* [[FreeBSD]] (full read/write support since version 12.0)
* [[macOS]] (read-only with ext4fuse, full with ExtFS)
* [[Windows]] (read–write without [[journaling file system|journaling]] with ext2fsd)
* [[KolibriOS]] (read-only)}}
| variants                = 
}}

'''ext4''' ('''fourth extended filesystem''') is a [[journaling file system]] for [[Linux]], developed as the successor to [[ext3]].

ext4 was initially a series of [[Backward compatibility|backward-compatible]] extensions to ext3, many of them originally developed by Cluster File Systems for the [[Lustre (file system)|Lustre file system]] between 2003 and 2006, meant to extend storage limits and add other performance improvements.<ref name="Mathur">{{cite web
 | title       = The new ext4 filesystem: current status and future plans
 | publisher   = Red Hat
 | location    = Ottawa, ON, CA
 | year        = 2007
 | work        = Proceedings of the Linux Symposium
 | url         = http://www.linuxsymposium.org/archives/OLS/Reprints-2007/mathur-Reprint.pdf
 | access-date  = 2008-01-15
 | first1       = Avantika
 | last1        = Mathur
 | first2      = MingMing
 | last2       = Cao
 | first3      = Suparna
 | last3       = Bhattacharya | author3-link = Suparna Bhattacharya
 | first4      = Andreas
 | last4       = Dilger
 | first5      = Alex
 | last5       = Zhuravlev (Tomas)
 | first6      = Laurent
 | last6       = Vivier
 | url-status  = dead
 | archive-url  = https://web.archive.org/web/20100706040230/http://www.linuxsymposium.org/archives/OLS/Reprints-2007/mathur-Reprint.pdf
 | archive-date = 2010-07-06}}</ref> However, other [[Linux kernel]] developers opposed accepting extensions to ext3 for stability reasons,<ref>{{cite web
 | url       = https://lkml.org/lkml/2006/6/9/183
 | date      = 2006-06-09
 | publisher = [[Linux kernel mailing list]]
 | first     = Linus
 | last      = Torvalds
 | title     = extents and 48bit ext3}}</ref> and proposed to [[Fork (software development)|fork]] the source code of ext3, rename it as ext4, and perform all the development there, without affecting existing ext3 users. This proposal was accepted, and on 28 June 2006, [[Theodore Ts'o]], the ext3 maintainer, announced the new plan of development for ext4.<ref>{{cite web
 | url       = https://lkml.org/lkml/2006/6/28/454
 | publisher = [[Linux kernel mailing list]]
 | first     = Theodore
 | last      = Ts'o
 | title     = Proposal and plan for ext2/3 future development work
 | date      = 2006-06-28}}</ref>

A preliminary development version of ext4 was included in version 2.6.19<ref>{{cite news
 | first       = Thorsten
 | last        = Leemhuis
 | title       = Higher and further: The innovations of Linux 2.6.28 (page 2)
 | url         = http://www.h-online.com/open/features/Kernel-Log-Higher-and-Further-The-innovations-of-Linux-2-6-28-746805.html
 | url-status  = dead
 | archive-url  = https://web.archive.org/web/20090103164710/http://www.heise-online.co.uk/open/Kernel-Log-Higher-and-Further-The-innovations-of-Linux-2-6-28--/features/112299
 | archive-date = 2009-01-03
 | publisher   = Heise Online
 | date        = 2008-12-23
 | access-date  = 2010-01-09}}</ref> of the Linux kernel. On 11 October 2008, the patches that mark ext4 as stable code were merged in the Linux 2.6.28 source code repositories,<ref>{{cite web
 | title        = ext4: Rename ext4dev to ext4
 | publisher    = Linus' kernel tree
 | url          = https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=03010a3350301baac2154fa66de925ae2981b7e3
 | access-date   = 2008-10-20
 | archive-url  = https://archive.today/20120529150649/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=03010a3350301baac2154fa66de925ae2981b7e3
 | archive-date = 29 May 2012
 | url-status   = dead}}</ref> denoting the end of the development phase and recommending ext4 adoption. Kernel 2.6.28, containing the ext4 filesystem, was finally released on 25 December 2008.<ref>{{cite news
 | first      = Thorsten
 | last       = Leemhuis
 | title      = Higher and further: The innovations of Linux 2.6.28
 | url        = http://www.heise-online.co.uk/open/Kernel-Log-Higher-and-Further-The-innovations-of-Linux-2-6-28--/features/112299
 | publisher  = Heise Online
 | date       = 2008-12-23
 }}</ref> On 15 January 2010, [[Google]] announced that it would upgrade its storage infrastructure from [[ext2]] to ext4.<ref>{{cite web
 | first      = Ryan
 | last       = Paul
 | title      = Google upgrading to Ext4, hires former Linux Foundation CTO
 | url        = https://arstechnica.com/open-source/news/2010/01/google-upgrading-to-ext4-hires-former-linux-foundation-cto.ars
 | website  = Ars Technica
 | date       = 2010-01-15
 }}</ref> On 14 December 2010, Google also announced it would use ext4, instead of [[YAFFS]], on [[Android (operating system)|Android 2.3]].<ref>{{Cite news |url=http://www.h-online.com/open/news/item/Android-2-3-Gingerbread-to-use-Ext4-file-system-1152775.html |title=Android 2.3 Gingerbread to use Ext4 file system |work=The H Open |date=14 December 2010 }}</ref>

== Adoption ==
ext4 is the default file system for many Linux distributions including [[Debian]] and [[Ubuntu]].<ref>{{Cite web |url=https://wiki.debian.org/FileSystem |title=FileSystem in debian |date=14 September 2019}}</ref>

== Features ==
{{More citations needed section|date=May 2024}}
; Large file system
: The ext4 filesystem can support volumes with sizes in theory up to 64&nbsp;[[zebibyte|ZiB]] and single files with sizes up to 16&nbsp;[[tebibytes|TiB]] with the standard 4&nbsp;[[kibibyte|KiB]] [[Block (data storage)|block size]], and volumes with sizes up to 1&nbsp;[[yobibyte|YiB]] with 64&nbsp;[[kibibyte|KiB]] clusters, though a limitation in the extent format makes 1&nbsp;[[exbibyte|EiB]] the practical limit.<ref>{{cite web
 | title       = ext4 – High Level Design
 | url         = https://www.kernel.org/doc/html/v6.1/filesystems/ext4/overview.html#blocks
 | website     = kernel.org
 | access-date = 8 December 2023
}}</ref> The maximum file, directory, and filesystem size limits grow at least proportionately with the filesystem block size up to the maximum 64&nbsp;KiB block size available on [[ARM Architecture|ARM]] and [[PowerPC]]/[[Power ISA]] CPUs.
; Extents
: [[Extent (file systems)|Extents]] replace the traditional [[Block (data storage)|block mapping]] scheme used by ext2 and ext3. An extent is a range of contiguous physical blocks, improving large-file performance and reducing fragmentation. A single extent in ext4 can map up to 128&nbsp;[[mebibytes|MiB]] of contiguous space with a 4&nbsp;KiB block size.<ref name = "Mathur" /> There can be four extents stored directly in the [[inode]]. When there are more than four extents to a file, the rest of the extents are indexed in a [[Tree (data structure)|tree]].<ref>{{cite web
 | url          = https://digital-forensics.sans.org/blog/2011/03/28/digital-forensics-understanding-ext4-part-3-extent-trees
 | last         = Pomeranz
 | first        = Hal
 | date         = 28 March 2011
 | title        = Understanding EXT4 (Part 3): Extent Trees
 | work         = SANS Digital Forensics and Incident Response Blog
 | archive-url  = https://web.archive.org/web/20190818050155/https://digital-forensics.sans.org/blog/2011/03/28/digital-forensics-understanding-ext4-part-3-extent-trees
 | archive-date = 18 August 2019}}</ref>
; Backward compatibility
: ext4 is [[backward-compatible]] with [[ext3]] and [[ext2]], making it possible to [[mount (computing)|mount]] ext3 and ext2 as ext4. This will slightly improve performance, because certain new features of the ext4 implementation can also be used with ext3 and ext2, such as the new block allocation algorithm, without affecting the on-disk format.<ref>{{Cite web |title=Anatomy of ext4 |url=https://developer.ibm.com/tutorials/l-anatomy-ext4 |access-date=2024-05-27 |website=IMB Developer}}</ref>
: ext3 is partially [[forward-compatible]] with ext4. Practically, ext4 will not mount as an ext3 filesystem out of the box, unless certain new features are disabled when creating it, such as <code>^extent</code>, <code>^flex_bg</code>, <code>^huge_file</code>, <code>^uninit_bg</code>, <code>^dir_nlink</code>, and <code>^extra_isize</code>.<ref>{{cite web
 | url         = http://www.linuxquestions.org/questions/red-hat-31/mount-of-ext4-created-without-extents-as-ext3-fails-on-rh6-2-a-936813/
 | title       = Mount of ext4 (created without extents) as ext3 fails on RH6.2
 | website     = www.linuxquestions.org
 | access-date = 8 December 2023
 | url-status  = live
 | archive-url = https://web.archive.org/web/20230805062315/https://www.linuxquestions.org/questions/red-hat-31/mount-of-ext4-created-without-extents-as-ext3-fails-on-rh6-2-a-936813/
 | archive-date = 5 August 2023}}</ref>
; Persistent pre-allocation
: ext4 can pre-allocate on-disk space for a file. To do this on most file systems, zeroes would be written to the file when created. In ext4 (and some other file systems such as [[XFS]]) <code>fallocate()</code>, a new system call in the Linux kernel, can be used. The allocated space would be guaranteed and likely contiguous. This situation has applications for media streaming and databases.{{Citation needed|date=May 2024}}
; Delayed allocation
: ext4 uses a performance technique called [[allocate-on-flush]], also known as ''delayed allocation''. That is, ext4 delays block allocation until data is flushed to disk; in contrast, some file systems allocate blocks immediately, even when the data goes into a write cache. Delayed allocation improves performance and reduces [[file system fragmentation|fragmentation]] by effectively allocating larger amounts of data at a time.<ref>{{Cite web |title=2. High Level Design — The Linux Kernel documentation |url=https://docs.kernel.org/filesystems/ext4/overview.html#block-and-inode-allocation-policy |access-date=2025-01-09 |website=docs.kernel.org}}</ref>
; Unlimited number of subdirectories
: ext4 does not limit the number of subdirectories in a single directory, except by the inherent size limit of the directory itself. (In ext3 a directory can have at most 32,000 subdirectories.)<ref>{{Cite web
 | url     = https://kernelnewbies.org/Ext4
 | title   = Ext4 – Linux Kernel Newbies
 | website = kernelnewbies.org}}</ref>{{Obsolete source|reason=Written on the page itself. However, the linked page (https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Sub_directory_scalability) doesn't support the claim, instead stating that there is a limit of 64000 subdirs. Take a look at https://man7.org/linux/man-pages/man5/ext4.5.html#FILE_SYSTEM_FEATURES, under dir_nlink|date=December 2023}} To allow for larger directories and continued performance, ext4 in Linux 2.6.23 and later turns on [[HTree]] [[Array data structure|indices]] (a specialized version of a [[B-tree]]) by default, which allows directories up to approximately 10–12 million entries to be stored in the 2-level HTree index and 2&nbsp;GB directory size limit for 4&nbsp;KiB block size, depending on the filename length. In Linux 4.12 and later the <code>large_dir</code> feature enabled a 3-level HTree and directory sizes over 2&nbsp;GB, allowing approximately 6 billion entries in a single directory.
; Journal checksums
: ext4 uses [[checksum]]s<ref>{{Cite web
 | url         = https://ext4.wiki.kernel.org/index.php/New_ext4_features#Metadata_Checksums
 | title       = New ext4 features – Ext4
 | website     = ext4.wiki.kernel.org
 | url-status  = live
 | access-date = 8 December 2023
 | archive-url = https://web.archive.org/web/20230923124620/https://ext4.wiki.kernel.org/index.php/New_ext4_features#Metadata_Checksums
 | archive-date = 23 September 2023}}</ref> in the journal to improve reliability, since the journal is one of the most used files of the disk. This feature has a side benefit: it can safely avoid a disk I/O wait during journaling, improving performance slightly. Journal checksumming was inspired by a research article from the [[University of Wisconsin]], titled ''IRON File Systems'',<ref>{{cite conference
 | title         = IRON File Systems
 | at            = Section 6.1, Paragraph 5 "Transactional Checksums"
 | url           = http://www.cs.wisc.edu/wind/Publications/iron-sosp05.pdf
 | last1         = Prabhakaran
 | first1        = Vijayan
 | last2         = Bairavasundaram
 | first2        = Lakshmi N.
 | last3         = Agrawal
 | first3        = Nitin
 | last4         = Gunawi
 | first4        = Haryadi S.
 | last5         = Arpaci-Dusseau
 | first5        = Andrea C.
 | last6         = Arpaci-Dusseau
 | first6        = Remzi H.
 | conference    = Symposium on Operating Systems Principles (SOSP '05)
 | conference-url = https://www.sigops.org/s/conferences/sosp/2005/default.htm
 | date          = October 2005
 | location      = Brighton, United Kingdom
 | publisher     = CS Dept, University of Wisconsin
 | access-date   = 8 December 2023}}</ref> with modifications within the implementation of compound transactions performed by the IRON file system (originally proposed by Sam Naghshineh in the RedHat summit).
; Metadata checksumming
: Support for metadata checksums was added in Linux kernel version 3.5 released in 2012.<ref>{{Cite web
 | url         = https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
 | title       = Ext4 Metadata Checksums – Ext4
 | website     = ext4.wiki.kernel.org
 | url-status  = live
 | access-date = 8 December 2023
 | archive-url = https://web.archive.org/web/20231106144434/https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
 | archive-date = 6 November 2023}}</ref><ref>{{Cite web
 | url     = https://kernelnewbies.org/Linux_3.5?highlight=(Metadata)%7C(checksumming)
 | title   = Linux_3.5 – Linux Kernel Newbies
 | website = kernelnewbies.org}}</ref> Many data structures were modified to add [[CRC-32C]] checksums but some only store the lower 16 bits of the 32-bit checksum as there isn't enough previously reserved space to fit the whole 4 bytes. In-place conversion can be done using <code>tune2fs -O metadata_csum</code>.<ref>{{cite web | title=2. High Level Design | website=The Linux Kernel  documentation | url=https://docs.kernel.org/filesystems/ext4/overview.html#checksums | access-date=2025-04-03}}</ref>
; Faster file-system checking
: In ext4 unallocated block groups and sections of the inode table are marked as such. This enables [[e2fsck]] to skip them entirely and greatly reduces the time it takes to check the file system. Linux 2.6.24 implements this feature.{{Citation needed|date=May 2024}}
; Multiblock allocator
: When ext3 appends to a file, it calls the block allocator, once for each block. Consequently, if there are multiple concurrent writers, files can easily become [[file system fragmentation|fragmented]] on disk. However, ext4 uses delayed allocation, which allows it to buffer data and allocate groups of blocks. Consequently, the multiblock allocator can make better choices about allocating files [[Contiguous data storage|contiguously]] on disk. The multiblock allocator can also be used when files are opened in O_DIRECT mode. This feature does not affect the disk format.
; Improved timestamps
: As computers become faster in general, and as Linux becomes used more for [[mission-critical]] applications, the granularity of second-based timestamps becomes insufficient. To solve this, ext4 provides [[timestamp]]s measured in [[nanoseconds]]. In addition, 2&nbsp;bits of the expanded timestamp field are added to the most significant bits of the seconds field of the timestamps to defer the [[year 2038 problem]] for an additional 408 years.<ref name="ext4-timestamp-range"/>
: ext4 also adds support for time-of-creation timestamps. But, as [[Theodore Ts'o]] points out, while it is easy to add an extra creation-date field in the [[inode]] (thus technically enabling support for these timestamps in ext4), it is more difficult to modify or add the necessary [[system calls]], like [[Stat (Unix)|stat()]] (which would probably require a new version) and the various [[Library (computing)|libraries]] that depend on them (like [[glibc]]). These changes will require coordination of many projects.<ref name="osdirmailinglistext4timestamps">{{cite web
 | url   = https://www.redhat.com/archives/ext3-users/2006-October/msg00015.html
 | title = Re: creation time stamps for ext4 ?
 | last  = Ts'o
 | first = Theodore
 | date  = 5 October 2006}}</ref> Therefore, the creation date stored by ext4 is currently only available to user programs on Linux via the <code>statx()</code> API.<ref name="statx">{{cite web
 | url   = https://lwn.net/Articles/718222/
 | title = Extending statx()
 | last  = Edge
 | first = Jake
 | date  = 2017-03-31
 | url-status = live
 | access-date = 8 December 2023
 | archive-url = https://web.archive.org/web/20230920041649/https://lwn.net/Articles/718222/
 | archive-date = 20 September 2023}}</ref>
; Project quotas
: Support for project quotas was added in Linux kernel 4.4 on 8 Jan 2016. This feature allows assigning [[disk quota]] limits to a particular project ID. The project ID of a file is a 32-bit number stored on each file and is inherited by all files and subdirectories created beneath a parent directory with an assigned project ID. This allows assigning quota limits to a particular subdirectory tree independent of file access permissions on the file, such as user and project quotas that are dependent on the UID and GID. While this is similar to a directory quota, the main difference is that the same project ID can be assigned to multiple top-level directories and is not strictly hierarchical.<ref name="projectquota">{{cite mailing list
 | url   = https://lwn.net/Articles/671627/
 | title = ext4: add project quota support
 | last  = Li
 | first = Xi
 | date  = 12 January 2016
 | url-status = live
 | access-date = 8 December 2023
 | archive-url = https://web.archive.org/web/20230920042516/https://lwn.net/Articles/671627/
 | archive-date = 20 September 2023}}</ref>
; Transparent encryption
: Support for transparent encryption was added in Linux kernel 4.1 in June 2015.<ref name="transparentencryption">{{cite web
 | url   = https://lwn.net/Articles/639427/
 | title = Ext4 encryption
 | last  = Ts'o
 | first = Theodore
 | date  = 8 April 2015
 | url-status = live
 | access-date = 8 December 2023
 | archive-url = https://web.archive.org/web/20231012232912/https://lwn.net/Articles/639427/
 | archive-date = 12 October 2023}}</ref><!--

Snapshot support is not yet merged into mainline kernel and is not shipped by any popular Linux distribution. It's misleading to call this a feature yet.

; Snapshot support
: Some file systems such as [[zfs]] and [[btrfs]] offer support for more advanced features such as snapshots. {{As of|2011|06|07}}, experimental support for snapshots has been available as a patch to the linux kernel.<ref>{{cite web

 | url         = http://article.gmane.org/gmane.comp.file-systems.ext4/25968
 | publisher   = [[Linux kernel mailing list]]
 | author      = Amir
 | title       = [PATCH v1 00/30] Ext4 snapshots
 | date        = 2011-06-07
 | access-date = 2012-05-01}}</ref>

 -->
; Lazy initialization
: The lazyinit feature allows cleaning of inode tables in background, speeding initialization when creating a new ext4 file system.<ref>{{Cite web
 | url     = https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem
 | title   = Ext4 Filesystem
 | website = Thomas-Krenn-Wiki
 | url-status = live
 | access-date = 8 December 2023
 | archive-url = https://web.archive.org/web/20220214022131/https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem
 | archive-date = 14 February 2022
}}</ref> It is available since 2010 in Linux kernel version 2.6.37.<ref>{{Cite web
 | url     = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bfff68738f1cb5c93dab1114634cea02aae9e7ba
 | title   = kernel/git/torvalds/linux.git – Linux kernel source tree
 | website = git.kernel.org}}</ref>
; Write barriers
: ext4 enables write barriers by default. It ensures that file system metadata is correctly written and ordered on disk, even when write caches lose power. This goes with a performance cost especially for applications that use fsync heavily or create and delete many small files. For disks with a battery-backed write cache, disabling barriers (option 'barrier=0') may safely improve performance.<ref>{{Cite web
 | url     = https://wiki.archlinux.org/index.php/ext4#Turning_barriers_off | title   = Ext4 –
 | website = ArchWiki}}</ref>

==Limitations==
In 2008, the principal developer of the ext3 and ext4 file systems, [[Theodore Ts'o]], stated that although ext4 has improved features, 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/information-technology/2009/04/linux-collaboration-summit-the-kernel-panel/
 | title      = Panelists ponder the kernel at Linux Collaboration Summit
 | first      = Ryan
 | last       = Paul
 | date       = 2009-04-14
 | 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> However, ext4 has continued to gain new features such as file encryption and metadata checksums.

The ext4 file system does not honor the "secure deletion" [[file attribute]], which is supposed to cause overwriting of files upon deletion. A patch to implement secure deletion was proposed in 2011, but did not solve the problem of sensitive data ending up in the file-system journal.<ref>{{cite web
 | first = Jonathan
 | last  = Corbet
 | title = Securely deleting files from ext4 filesystems
 | url   = https://lwn.net/Articles/462437/
 | date  = 11 October 2011}}</ref>

==Delayed allocation and potential data loss==
Because delayed allocation changes the behavior that programmers have been relying on with ext3, the feature poses some additional risk of data loss in cases where the system crashes or loses power before all of the data has been written to disk. Due to this, ext4 in kernel versions 2.6.30 and later automatically handles these cases as ext3 does.

The typical scenario in which this might occur is a program replacing the contents of a file without forcing a write to the disk with [[fsync]]. There are two common ways of replacing the contents of a file on Unix systems:<ref name=ext4-kerneldoc />
* <code>fd=[[Open (system call)|open]]("file", O_TRUNC); write(fd, data); close(fd);</code>
: In this case, an existing file is truncated at the time of open (due to <code>O_TRUNC</code> flag), then new data is written out. Since the write can take some time, there is an opportunity of losing contents even with ext3, but usually very small. However, because ext4 can delay writing file data for a long time, this opportunity is much greater.
: There are several problems that can arise:
:# If the write does not succeed (which may be due to error conditions in the writing program, or due to external conditions such as a full disk), then both the original version ''and'' the new version of the file will be lost, and the file may be corrupted because only a part of it has been written.
:# If other processes access the file while it is being written, they see a corrupted version.
:# If other processes have the file open and do not expect its contents to change, those processes may crash. One notable example is a shared library file which is mapped into running programs.
:Because of these issues, often the following idiom is preferred over the one above:
* <code>fd=open("file.new"); write(fd, data); close(fd); [[rename (C)|rename]]("file.new", "file");</code>
: A new temporary file ("file.new") is created, which initially contains the new contents. Then the new file is renamed over the old one. Replacing files by the <code>rename()</code> call is guaranteed to be atomic by [[POSIX]] standards – i.e. either the old file remains, or it is overwritten with the new one. Because the ext3 default "ordered" journaling mode guarantees file data is written out on disk before metadata, this technique guarantees that either the old or the new file contents will persist on disk. ext4's delayed allocation breaks this expectation, because the file write can be delayed for a long time, and the rename is usually carried out before new file ''contents'' reach the disk.

Using <code>fsync()</code> more often to reduce the risk for ext4 could lead to performance penalties on ext3 filesystems mounted with the <code>data=ordered</code> flag (the default on most Linux distributions). Given that both file systems will be in use for some time, this complicates matters for end-user application developers. In response, ext4 in Linux kernels 2.6.30 and newer detect the occurrence of these common cases and force the files to be allocated immediately. For a small cost in performance, this provides semantics similar to ext3 ordered mode and increases the chance that either version of the file will survive the crash. This new behavior is enabled by default, but can be disabled with the "noauto_da_alloc" mount option.<ref name=ext4-kerneldoc>{{cite web
 | date  = 2009-03-28
 | title = ext4 documentation in Linux kernel source
 | url   = https://www.kernel.org/doc/Documentation/filesystems/ext4.txt}}</ref>

The new patches have become part of the mainline kernel 2.6.30, but various distributions chose to backport them to 2.6.28 or 2.6.29.<ref>[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781?comments=all Ubuntu bug #317781] Long discussion between Ubuntu developers and Theodore Ts'o on potential data loss</ref>

These patches don't completely prevent potential data loss or help at all with new files. The only way to be safe is to write and use software that does <code>fsync()</code> when it needs to. Performance problems can be minimized by limiting crucial disk writes that need <code>fsync()</code> to occur less frequently.<ref>[http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ Thoughts by Ted blog entry, 12 March 2009] A blog posting of Theodore Ts'o on the subject</ref>

==Implementation==
[[File:Simplified Structure of the Linux Kernel.svg|thumb|Simplified structure of the Linux kernel: ext4 is implemented between the Linux kernel Virtual File System and the generic block layer.]]

Linux kernel Virtual File System is a subsystem or layer inside of the Linux kernel. It is the result of an attempt to integrate multiple file systems into an orderly single structure. The key idea, which dates back to the pioneering work done by Sun Microsystems employees in 1986,<ref>Kleiman</ref> is to abstract out that part of the file system that is common to all file systems and put that code in a separate layer that calls the underlying concrete file systems to actually manage the data.

All system calls related to files (or pseudo files) are directed to the Linux kernel Virtual File System for initial processing. These calls, coming from user processes, are the standard POSIX calls, such as <code>[[open (system call)|open]]</code>, <code>[[read (system call)|read]]</code>, <code>[[write (system call)|write]]</code>, <code>[[lseek (system call)|lseek]]</code>, etc.

==Interoperability==

Although designed for and primarily used with Linux, an ext4 file system can be accessed via other operating systems via interoperability tools.

[[Microsoft Windows|Windows]] provides access via its [[Windows Subsystem for Linux]] (WSL) technology. Specifically, the second major version, WSL 2, is the first version with ext4 support. It was first released in [[Windows 10 version history|Windows 10 Insider Preview Build 20211]].<ref>{{cite web |url=https://blogs.windows.com/windows-insider/2020/09/10/announcing-windows-10-insider-preview-build-20211/ |title=Announcing Windows 10 Insider Preview Build 20211 |author=Brandon LeBlanc |date=10 September 2020 |website=Windows Blogs |access-date=25 May 2021}}</ref><ref>{{cite web |url=https://devblogs.microsoft.com/commandline/access-linux-filesystems-in-windows-and-wsl-2/ |title=Access Linux filesystems in Windows and WSL 2 |author=Pierre Boulay |date=10 September 2020 |website=Windows Command Line |access-date=25 May 2021}}</ref><ref>{{cite web |url=https://docs.microsoft.com/en-gb/windows/wsl/wsl2-mount-disk |title=Get started mounting a Linux disk in WSL 2 |website=Microsoft Docs |access-date=25 May 2021}}</ref><ref>{{cite web |url=https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/ |title=WSL 2 is now available in Windows Insiders |author=Craig Loewen |date=12 June 2019 |website=Windows Command Line |access-date=25 May 2021}}</ref> WSL 2 requires Windows 10 version 1903 or higher, with build 18362 or higher, for x64 systems, and version 2004 or higher, with build 19041 or higher, for ARM64 systems.<ref>{{cite web |url=https://docs.microsoft.com/en-gb/windows/wsl/install-win10 |title=Windows Subsystem for Linux Installation Guide for Windows 10 |website=Windows Docs |access-date=25 May 2021}}</ref>

[[Paragon Software Group|Paragon Software]] offers commercial products that provide full read/write access for ext2/3/4 {{endash}} ''Linux File Systems for Windows''<ref>{{cite web |url=https://www.paragon-software.com/home/linuxfs-windows/ |title=Linux File Systems for Windows |website=Paragon Software |access-date=25 May 2021}}</ref> and ''extFS for Mac''.<ref>{{cite web |url=https://www.paragon-software.com/home/extfs-mac/ |title=extFS for Mac |website=Paragon Software |access-date=25 May 2021}}</ref>

The free software ''ext4fuse'' provides limited (read-only) support.

== General Architecture ==
The ext4 filesystem divides the partition it resides into smaller chunks called blocks (a group of sectors, usually between 1&nbsp;KiB and 64&nbsp;KiB). By default, the block size is the same as the page size (4&nbsp;KiB), but it can be configured with {{Mono|mkfs}} during filesystem creation. Blocks are grouped into larger chunks called block groups.

=== Superblock ===
{{Main|Superblock (file system)}}
This is the heart of the filesystem; it resides in only one block of the disk.<ref>https://docs.kernel.org/filesystems/ext4/overview.html#layout</ref> It is usually the first item in a block group, except for group 0, where the first few bytes are reserved for the [[boot sector]]. The Superblock is vital for the filesystem – as such, backup copies are written across partitions at filesystem creation time, so it can be recovered in case of corruption.

=== Group Descriptor Table ===
GDT comes in second after superblock. GDT stores block group descriptors of each block group on the filesystem. It resides on more than one block on disk. Each GDT is 64 bytes in size. This structure is also vital for the filesystem; as such, redundant backups are stored across the filesystem.

=== Block Bitmap === 
The Block bitmap tracks the block usage status of all blocks of a block group. Each bit in the bitmap represents a block. If a block is in use, its corresponding bit will be set, otherwise it will be unset. The location of the block bitmap is not fixed, so its position is stored in respective block group descriptors.

=== Inode Bitmap ===
Similar to the Block bitmap, the Inode bitmap's location is also not fixed, therefore the group descriptor points to the location of the Inode bitmap. The Inode bitmap tracks usage of inodes. Each bit in the bitmap represents an inode. If an inode is in use then its corresponding bit in Inode bitmap will be set, otherwise it will be unset.

=== Block Group Descriptors ===
Each block group is represented by its block group descriptor. It has vital information for the block group like free [[inode]]s, free blocks and the location of inode bitmap, block bitmap and the inode table of that particular block group.

== Flexible block groups ==
Ext4 introduced flexible block groups. In {{Mono|flex_bg}}, several block groups are grouped into one logical block group. Block bitmap and inode bitmap of first block group are expanded
to include the bitmap and the inode table of other block groups.

== See also ==
* {{Annotated link|Btrfs}}
* {{Annotated link|Comparison of file systems}}
* {{Annotated link|Extended file attributes}}
* {{Annotated link|e2fsprogs}}
* {{Annotated link|Ext2Fsd}}
* {{Annotated link|JFS (file system)|JFS}}
* {{Annotated link|List of file systems}}
* {{Annotated link|List of default file systems}}
* {{Annotated link|Reiser4}}
* {{Annotated link|XFS}}
* {{Annotated link|ZFS}}

== References ==
{{Reflist}}

== External links ==
* [https://www.kernel.org/doc/Documentation/filesystems/ext4.txt ext4 documentation in Linux kernel source]
* [https://archive.today/20120712143749/kerneltrap.org/node/6776 Theodore Ts'o's discussion on ext4], 29 June 2006
* [http://ols.fedoraproject.org/OLS/Reprints-2007/sato-Reprint.pdf "ext4 online defragmentation"] {{Webarchive|url=https://web.archive.org/web/20191230032039/https://ols.fedoraproject.org/OLS/Reprints-2007/sato-Reprint.pdf |date=30 December 2019 }} (materials from Ottawa Linux Symposium 2007)
* [https://www.kernel.org/doc/ols/2007/ols2007v2-pages-21-34.pdf "The new ext4 filesystem: current status and future plans"] (materials from Ottawa Linux Symposium 2007)
* [http://heise-online.co.uk/news/Kernel-Log-Ext4-completes-development-phase-as-interim-step-to-btrfs--/111742 Kernel Log: Ext4 completes development phase as interim step to btrfs], 17 October 2008
* [http://ols.fedoraproject.org/OLS/Reprints-2008/kumar-reprint.pdf "Ext4 block and inode allocator improvements"] {{Webarchive|url=https://web.archive.org/web/20100331074732/http://ols.fedoraproject.org/OLS/Reprints-2008/kumar-reprint.pdf |date=31 March 2010 }} (materials from Ottawa Linux Symposium 2008)
* [http://usenix.org/event/lsf07/tech/cao_m.pdf "Ext4: The Next Generation of Ext2/3 Filesystem"]
* [https://ext4.wiki.kernel.org/ Ext4 (and Ext2/Ext3) Wiki]
* [http://kernelnewbies.org/Ext4 Ext4] wiki at kernelnewbies.org
* Native Windows port of Ext4 and other FS in [https://web.archive.org/web/20120111062641/http://www.crossmeta.org/redmine CROSSMETA]
* [http://ext2read.sourceforge.net/ Ext2read] A windows application to read/copy ext2/ext3/ext4 files with extent and LVM2 support.
* [https://web.archive.org/web/20120723091043/http://www.ext2fsd.com/ Ext2Fsd] Open source ext2/ext3/ext4 read/write file system driver for Windows. ext4 is supported from version 0.50 onwards 
* [https://github.com/gerard/ext4fuse Ext4fuse] Open source read-only ext4 driver for [[Filesystem in Userspace|FUSE]]. (Supports [[Mac OS X]] 10.5 and later, using [https://code.google.com/p/macfuse/ MacFuse])
* [https://blogs.oracle.com/linux/post/understanding-ext4-disk-layout-part-1 oracle post] Understanding ext4 disk layout 
{{Filesystem}}

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