ext4

ext4 (fourth extended filesystem) is a journaling file

ext4
system for Linux, developed as the successor to ext3.
Developer(s) Mingming Cao, Andreas
ext4 was initially a series of backward-compatible Dilger, Alex Zhuravlev
extensions to ext3, many of them originally developed (Tomas), Dave Kleikamp,
by Cluster File Systems for the Lustre file system Theodore Ts'o, Eric
between 2003 and 2006, meant to extend storage Sandeen, Sam
limits and add other performance improvements.[4] Naghshineh, others
However, other Linux kernel developers opposed
Full name Fourth extended file
accepting extensions to ext3 for stability reasons,[5] system
and proposed to fork the source code of ext3, rename
Introduced 10 October 2006 with
it as ext4, and perform all the development there,
Linux 2.6.19
without affecting existing ext3 users. This proposal
was accepted, and on 28 June 2006, Theodore Ts'o, Preceded by ext3
the ext3 maintainer, announced the new plan of Partition IDs 0x83: MBR / EBR.
development for ext4.[6] EBD0A0A2-B9E5-
4433-87C0-
A preliminary development version of ext4 was
68B6B72699C7: GPT
included in version 2.6.19[7] of the Linux kernel. On
Windows BDP.[1]
11 October 2008, the patches that mark ext4 as stable
0FC63DAF-8483-
code were merged in the Linux 2.6.28 source code
4772-8E79-
repositories,[8] denoting the end of the development
3D69D8477DE4: GPT
phase and recommending ext4 adoption. Kernel
Linux filesystem
2.6.28, containing the ext4 filesystem, was finally [1]
data.
released on 25 December 2008.[9] On 15 January
933AC7E1-2EB4-
2010, Google announced that it would upgrade its
4F13-B844-
storage infrastructure from ext2 to ext4.[10] On 14
0E14E2AEF915: GPT
December 2010, Google also announced it would use
/home partition.[2]
ext4, instead of YAFFS, on Android 2.3.[11]
3B8F8425-20E0-
Its improvements over ext3 include a date range that
4F3B-907F-
ends in the year 2446 instead of 2038, a timestamp
1A25A76F98E8: GPT
accuracy of a nanosecond instead of one second, and
/srv (server data)
higher size limits.[12][13]
partition.
Structures
Adoption Directory contents Linked list, hashed B-tree
File allocation Extents / Bitmap
ext4 is the default file system for many Linux
Bad blocks Table
distributions including Debian and Ubuntu.[14]
Limits
 Max volume size 1 EiB
Features Max file size 16–256 TiB (for 4–64 KiB
block size)

Large file system Max no. of files 4 billion (specified at

The ext4 filesystem can support volumes filesystem creation time)
with sizes in theory up to 64 ZiB and single
Max filename length 255 bytes (fewer for
files with sizes up to 16 TiB with the
standard 4 KiB block size, and volumes multibyte character
with sizes up to 1 YiB with 64 KiB clusters, encodings such as
though a limitation in the extent format Unicode)
makes 1 EiB the practical limit.[15] The Allowed filename All characters and
maximum file, directory, and filesystem size
characters character sequences
limits grow at least proportionately with the
filesystem block size up to the maximum permitted, except for
64 KiB block size available on ARM and NULL ('\0'), '/', and the
PowerPC/Power ISA CPUs. special file names "." and
Extents ".." which are reserved
Extents replace the traditional block for indicating
mapping scheme used by ext2 and ext3.
(respectively) current and
An extent is a range of contiguous physical
blocks, improving large-file performance parent directories.
and reducing fragmentation. A single extent Features
in ext4 can map up to 128 MiB of
Dates recorded Modification (mtime),
contiguous space with a 4 KiB block size.[4]
There can be four extents stored directly in data or attribute
the inode. When there are more than four modification (ctime),
extents to a file, the rest of the extents are access (atime), deletion
indexed in a tree.[16] (dtime), creation (crtime)
Backward compatibility
Date range 14 December 1901 – 10
ext4 is backward-compatible with ext3 and
ext2, making it possible to mount ext3 and May 2446[3]
ext2 as ext4. This will slightly improve Date resolution Nanosecond
performance, because certain new features
Forks No
of the ext4 implementation can also be
used with ext3 and ext2, such as the new Attributes acl, bh, bsddf,
block allocation algorithm, without affecting commit=nrsec,
the on-disk format.[17] data=journal,
ext3 is partially forward-compatible with
data=ordered,
ext4. Practically, ext4 will not mount as an
ext3 filesystem out of the box, unless data=writeback, delalloc,
certain new features are disabled when extents, journal_dev,
creating it, such as ^extent, ^flex_bg, mballoc, minixdf, noacl,
^huge_file, ^uninit_bg, nobh, nodelalloc,
^dir_nlink, and ^extra_isize.[18] noextents, nomballoc,
Persistent pre-allocation nombcache,
ext4 can pre-allocate on-disk space for a nouser_xattr, oldalloc,
file. To do this on most file systems, zeroes orlov, user_xattr
would be written to the file when created. In
ext4 (and some other file systems such as File system Unix permissions, POSIX
XFS) fallocate(), a new system call in permissions ACLs
the Linux kernel, can be used. The Transparent No
allocated space would be guaranteed and compression
likely contiguous. This situation has
 applications for media streaming and Transparent Yes
databases. encryption
Delayed allocation
ext4 uses a performance technique called Data deduplication No
allocate-on-flush, also known as delayed Other
allocation. That is, ext4 delays block
allocation until data is flushed to disk; in Supported Linux
contrast, some file systems allocate blocks operating systems FreeBSD (full read/write
immediately, even when the data goes into support since version
a write cache. Delayed allocation improves
12.0)
performance and reduces fragmentation by
effectively allocating larger amounts of data macOS (read-only with
at a time. [19] ext4fuse, full with ExtFS)
Unlimited number of subdirectories Windows (read–write
ext4 does not limit the number of
without journaling with
subdirectories in a single directory, except
by the inherent size limit of the directory ext2fsd)
itself. (In ext3 a directory can have at most KolibriOS (read-only)
32,000 subdirectories.) [20] To allow for
larger directories and continued performance, ext4 in Linux 2.6.23 and later turns on
HTree 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 GB
directory size limit for 4 KiB block size, depending on the filename length. In Linux 4.12
and later the large_dir feature enabled a 3-level HTree and directory sizes over 2 GB,
allowing approximately 6 billion entries in a single directory.
Journal checksums
ext4 uses checksums[21] 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,[22] 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.[23][24] 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 tune2fs
-O metadata_csum.[25]
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.
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 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 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 timestamps measured in nanoseconds. In addition, 2 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.[3]
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() (which would probably require a new version) and the various
libraries that depend on them (like glibc). These changes will require coordination of many
projects.[26] Therefore, the creation date stored by ext4 is currently only available to user
programs on Linux via the statx() API.[27]
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.[28]
Transparent encryption
Support for transparent encryption was added in Linux kernel 4.1 in June 2015.[29]
Lazy initialization
The lazyinit feature allows cleaning of inode tables in background, speeding initialization
when creating a new ext4 file system.[30] It is available since 2010 in Linux kernel version
2.6.37.[31]
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.[32]

Limitations
In 2008, the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that although
ext4 has improved features over ext3, it is not a major advancement, it is based on older technology. Ts'o
commented at the time that Btrfs may be the better direction because "it offers improvements in
scalability, reliability, and ease of management".[33] Btrfs also has "a number of the same design ideas
that reiser3/4 had" that made it seem attractive at the time.[34] However, Ts'o and many contributors from
IBM, Google, SuSE, Huawei, and others, have continued to maintain and improve ext4 with new features
such as file encryption, metadata checksums, and case insensitive filenames.

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.[35]
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:[36]

fd=open("file", O_TRUNC); write(fd, data); close(fd);

In this case, an existing file is truncated at the time of open (due to O_TRUNC 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:
1. 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.
2. If other processes access the file while it is being written, they see a corrupted version.
3. 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:

fd=open("[Link]"); write(fd, data); close(fd); rename("[Link]",

"file");

A new temporary file ("[Link]") is created, which initially contains the new contents. Then
the new file is renamed over the old one. Replacing files by the rename() 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 fsync() more often to reduce the risk for ext4 could lead to performance penalties on ext3
filesystems mounted with the data=ordered 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.[36]
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.[37]

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 fsync() when it needs to. Performance problems can be
minimized by limiting crucial disk writes that need fsync() to occur less frequently.[38]

Implementation
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,[39] 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. Simplified structure of the Linux kernel:
ext4 is implemented between the Linux
All system calls related to files (or pseudo files) are directed kernel Virtual File System and the
to the Linux kernel Virtual File System for initial processing. generic block layer.
These calls, coming from user processes, are the standard
POSIX calls, such as open, read, write, lseek, etc.

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

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
Insider Preview Build 20211.[40][41][42][43] 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.[44]

Paragon Software offers commercial products that provide full read/write access for ext2/3/4 – Linux File
Systems for Windows[45] and extFS for Mac.[46]

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 KiB and 64 KiB). By default, the block size is the same as the page size (4 KiB), but it
can be configured with mkfs during filesystem creation. Blocks are grouped into larger chunks called
block groups.
Superblock
This is the heart of the filesystem; it resides in only one block of the disk.[47] 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 inodes, 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 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
Btrfs – Copy-on-write file system
Comparison of file systems
Extended file attributes – Set of file system features
e2fsprogs – Software to maintain ext* file systems
Ext2Fsd – Open source filesystem driver
 JFS – File system
List of file systems
List of default file systems
Reiser4 – Journaling file system for Linux
XFS – Journaling file system for IRIX and Linux
ZFS – Copy-on-write file system

References
1. Previously, Linux used the same GUID for the data partitions as Windows (Basic data
partition: 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:
0FC63DAF-8483-4772-8E79-3D69D8477DE4) was defined jointly by GPT fdisk and GNU
Parted developers. It is identified as type code 0x8300 in GPT fdisk. (See definitions in
gdisk's [Link] ([Link]
k;a%3Dblob_plain;f%[Link];hb%3DHEAD))
2. "DiscoverablePartitionsSpec" ([Link]
artitionsSpec/). [Link]. Retrieved 7 April 2018.
3. "ext4: Fix handling of extended tv_sec" ([Link]
[Link]/commit/?id=a4dad1ae24f850410c4e60f22823cba1289b8d52). Linux-stable kernel
tree. Retrieved 14 February 2017.
4. Mathur, Avantika; Cao, MingMing; Bhattacharya, Suparna; Dilger, Andreas; Zhuravlev
(Tomas), Alex; Vivier, Laurent (2007). "The new ext4 filesystem: current status and future
plans" ([Link]
es/OLS/Reprints-2007/[Link]) (PDF). Proceedings of the Linux Symposium.
Ottawa, ON, CA: Red Hat. Archived from the original ([Link]
es/OLS/Reprints-2007/[Link]) (PDF) on 6 July 2010. Retrieved 15 January
2008.
5. Torvalds, Linus (9 June 2006). "extents and 48bit ext3" ([Link]
Linux kernel mailing list.
6. Ts'o, Theodore (28 June 2006). "Proposal and plan for ext2/3 future development work" (htt
ps://[Link]/lkml/2006/6/28/454). Linux kernel mailing list.
7. Leemhuis, Thorsten (23 December 2008). "Higher and further: The innovations of Linux
2.6.28 (page 2)" ([Link]
k/open/Kernel-Log-Higher-and-Further-The-innovations-of-Linux-2-6-28--/features/112299).
Heise Online. Archived from the original ([Link]
[Link]) on 3 January 2009.
Retrieved 9 January 2010.
8. "ext4: Rename ext4dev to ext4" ([Link]
t;a=commit;h=03010a3350301baac2154fa66de925ae2981b7e3). Linus' kernel tree.
Retrieved 20 October 2008.
9. Leemhuis, Thorsten (23 December 2008). "Higher and further: The innovations of Linux
2.6.28" ([Link]
-of-Linux-2-6-28--/features/112299). Heise Online.
10. Paul, Ryan (15 January 2010). "Google upgrading to Ext4, hires former Linux Foundation
CTO" ([Link]
[Link]). Ars Technica.
11. "Android 2.3 Gingerbread to use Ext4 file system" ([Link]
[Link]). The H Open. 14
December 2010.
12. ext4: Fix handling of extended tv_sec - kernel/git/stable/[Link] - Linux kernel stable tree (ht
tps://[Link]/pub/scm/linux/kernel/git/stable/[Link]/commit/?id=a4dad1ae24f850410c
4e60f22823cba1289b8d52)
13. "ext4 General Information — The Linux Kernel documentation" ([Link]
tml/v6.17-rc1/admin-guide/[Link]). Retrieved 17 August 2025.
14. "FileSystem in debian" ([Link] 14 September 2019.
15. "ext4 – High Level Design" ([Link]
html#blocks). [Link]. Retrieved 8 December 2023.
16. Pomeranz, Hal (28 March 2011). "Understanding EXT4 (Part 3): Extent Trees" ([Link]
[Link]/web/20190818050155/[Link]
orensics-understanding-ext4-part-3-extent-trees). SANS Digital Forensics and Incident
Response Blog. Archived from the original ([Link]
8/digital-forensics-understanding-ext4-part-3-extent-trees) on 18 August 2019.
17. "Anatomy of ext4" ([Link] IMB Developer.
Retrieved 27 May 2024.
18. "Mount of ext4 (created without extents) as ext3 fails on RH6.2" ([Link]
rg/questions/red-hat-31/mount-of-ext4-created-without-extents-as-ext3-fails-on-rh6-2-a-9368
13/). [Link]. Archived ([Link]
s://[Link]/questions/red-hat-31/mount-of-ext4-created-without-extents-as-e
xt3-fails-on-rh6-2-a-936813/) from the original on 5 August 2023. Retrieved 8 December
2023.
19. "2. High Level Design — The Linux Kernel documentation" ([Link]
ms/ext4/[Link]#block-and-inode-allocation-policy). [Link]. Retrieved
9 January 2025.
20. "Ext4 – Linux Kernel Newbies" ([Link] [Link].
21. "New ext4 features – Ext4" ([Link]
data_Checksums). [Link]. Archived ([Link]
620/[Link] from
the original on 23 September 2023. Retrieved 8 December 2023.
22. Prabhakaran, Vijayan; Bairavasundaram, Lakshmi N.; Agrawal, Nitin; Gunawi, Haryadi S.;
Arpaci-Dusseau, Andrea C.; Arpaci-Dusseau, Remzi H. (October 2005). IRON File Systems
([Link] (PDF). Symposium on Operating
Systems Principles (SOSP '05) ([Link]
m). Brighton, United Kingdom: CS Dept, University of Wisconsin. Section 6.1, Paragraph 5
"Transactional Checksums". Retrieved 8 December 2023.
23. "Ext4 Metadata Checksums – Ext4" ([Link]
Checksums). [Link]. Archived ([Link]
ttps://[Link]/[Link]/Ext4_Metadata_Checksums) from the original on 6
November 2023. Retrieved 8 December 2023.
24. "Linux_3.5 – Linux Kernel Newbies" ([Link]
ta)%7C(checksumming)). [Link].
25. "2. High Level Design" ([Link]
The Linux Kernel documentation. Retrieved 3 April 2025.
26. Ts'o, Theodore (5 October 2006). "Re: creation time stamps for ext4 ?" ([Link]
om/archives/ext3-users/2006-October/[Link]).
27. Edge, Jake (31 March 2017). "Extending statx()" ([Link] Archived
([Link] from the
original on 20 September 2023. Retrieved 8 December 2023.
28. Li, Xi (12 January 2016). "ext4: add project quota support" ([Link]
(Mailing list). Archived ([Link]
s/671627/) from the original on 20 September 2023. Retrieved 8 December 2023.
29. Ts'o, Theodore (8 April 2015). "Ext4 encryption" ([Link] Archived
([Link] from the
original on 12 October 2023. Retrieved 8 December 2023.
30. "Ext4 Filesystem" ([Link] Thomas-Krenn-
Wiki. Archived ([Link]
m/en/wiki/Ext4_Filesystem) from the original on 14 February 2022. Retrieved 8 December
2023.
31. "kernel/git/torvalds/[Link] – Linux kernel source tree" ([Link]
ernel/git/torvalds/[Link]/commit/?id=bfff68738f1cb5c93dab1114634cea02aae9e7ba).
[Link].
32. "Ext4 –" ([Link] ArchWiki.
33. Paul, Ryan (14 April 2009). "Panelists ponder the kernel at Linux Collaboration Summit" (htt
ps://[Link]/information-technology/2009/04/linux-collaboration-summit-the-kernel-
panel/). Ars Technica. Retrieved 22 August 2009.
34. Theodore Ts'o (1 August 2008). "Re: reiser4 for 2.6.27-rc1" ([Link]
7). linux-kernel (Mailing list). Retrieved 31 December 2010.
35. Corbet, Jonathan (11 October 2011). "Securely deleting files from ext4 filesystems" ([Link]
[Link]/Articles/462437/).
36. "ext4 documentation in Linux kernel source" ([Link]
systems/[Link]). 28 March 2009.
37. Ubuntu bug #317781 ([Link]
ents=all) Long discussion between Ubuntu developers and Theodore Ts'o on potential data
loss
38. Thoughts by Ted blog entry, 12 March 2009 ([Link]
allocation-and-the-zero-length-file-problem/) A blog posting of Theodore Ts'o on the subject
39. Kleiman
40. Brandon LeBlanc (10 September 2020). "Announcing Windows 10 Insider Preview Build
20211" ([Link]
ider-preview-build-20211/). Windows Blogs. Retrieved 25 May 2021.
41. Pierre Boulay (10 September 2020). "Access Linux filesystems in Windows and WSL 2" (htt
ps://[Link]/commandline/access-linux-filesystems-in-windows-and-wsl-2/).
Windows Command Line. Retrieved 25 May 2021.
42. "Get started mounting a Linux disk in WSL 2" ([Link]
l/wsl2-mount-disk). Microsoft Docs. Retrieved 25 May 2021.
43. Craig Loewen (12 June 2019). "WSL 2 is now available in Windows Insiders" ([Link]
[Link]/commandline/wsl-2-is-now-available-in-windows-insiders/). Windows
Command Line. Retrieved 25 May 2021.
44. "Windows Subsystem for Linux Installation Guide for Windows 10" ([Link]
m/en-gb/windows/wsl/install-win10). Windows Docs. Retrieved 25 May 2021.
45. "Linux File Systems for Windows" ([Link]
s/). Paragon Software. Retrieved 25 May 2021.
46. "extFS for Mac" ([Link] Paragon Software.
Retrieved 25 May 2021.
47. "2. High Level Design — the Linux Kernel documentation" ([Link]
s/ext4/[Link]#layout).
External links
ext4 documentation in Linux kernel source ([Link]
stems/[Link])
Theodore Ts'o's discussion on ext4 ([Link]
ode/6776), 29 June 2006
"ext4 online defragmentation" ([Link]
pdf) Archived ([Link]
S/Reprints-2007/[Link]) 30 December 2019 at the Wayback Machine (materials
from Ottawa Linux Symposium 2007)
"The new ext4 filesystem: current status and future plans" ([Link]
07/[Link]) (materials from Ottawa Linux Symposium 2007)
Kernel Log: Ext4 completes development phase as interim step to btrfs ([Link]
[Link]/news/Kernel-Log-Ext4-completes-development-phase-as-interim-step-to-btrfs--/11174
2), 17 October 2008
"Ext4 block and inode allocator improvements" ([Link]
008/[Link]) Archived ([Link]
[Link]/OLS/Reprints-2008/[Link]) 31 March 2010 at the Wayback
Machine (materials from Ottawa Linux Symposium 2008)
"Ext4: The Next Generation of Ext2/3 Filesystem" ([Link]
pdf)
Ext4 (and Ext2/Ext3) Wiki ([Link]
Ext4 ([Link] wiki at [Link]
Native Windows port of Ext4 and other FS in CROSSMETA ([Link]
120111062641/[Link]
Ext2read ([Link] A windows application to read/copy
ext2/ext3/ext4 files with extent and LVM2 support.
Ext2Fsd ([Link] Open
source ext2/ext3/ext4 read/write file system driver for Windows. ext4 is supported from
version 0.50 onwards
Ext4fuse ([Link] Open source read-only ext4 driver for FUSE.
(Supports Mac OS X 10.5 and later, using MacFuse ([Link]
oracle post ([Link]
Understanding ext4 disk layout

Retrieved from "[Link]