Ext4 Design
From Ext4
(Difference between revisions)
Line 3: | Line 3: | ||
* Ext3: default filesystem for many users, reputation of dependability & compatibility, leave existing ext3 users undisturbed, stable | * Ext3: default filesystem for many users, reputation of dependability & compatibility, leave existing ext3 users undisturbed, stable | ||
* Scaling up to support large filesystems: Storage advancements, Increasing data storage requirements, only large filesystem users move to ext4 | * Scaling up to support large filesystems: Storage advancements, Increasing data storage requirements, only large filesystem users move to ext4 | ||
− | * Features requiring on-disk format change: nanosec timestamps, fast | + | * Features requiring on-disk format change: nanosec timestamps, fast extent allocation, preallocation |
* Reliability wrt on-disk corruption | * Reliability wrt on-disk corruption | ||
* 64 bit JBD split | * 64 bit JBD split | ||
* Forward compatibility/upgradeability | * Forward compatibility/upgradeability | ||
+ | * Multiblock allocation | ||
+ | * Delayed allocation | ||
+ | |||
+ | '''Ext4 Extents''' <br> | ||
+ | |||
+ | The core of the Ext4 FS is the support for extents. An extent is simply a set of blocks which are logically contiguous within the file and also on the underlying block device. Most contemporary filesystems put considerable effort into allocating contiguous blocks for files as a way of making I/O operations faster, so blocks which are logically contiguous within the file often are also contiguous on-disk. As a result, storing the file structure as extents should result in significant compression of the file's metadata, since a single extent can replace a large number of block pointers. The reduction in metadata should enable faster access as well. | ||
'''On-Disk Structures''' <br> | '''On-Disk Structures''' <br> | ||
Line 34: | Line 40: | ||
}; | }; | ||
</pre> | </pre> | ||
+ | |||
+ | |||
+ | '''External References''' <br> | ||
+ | [https://foss.in/2006/cfp/slides/ext4-foss.pdf] | ||
+ | [http://ext2.sourceforge.net/2005-ols/2005-ols-ext3-presentation.pdf] | ||
+ | [http://ext2.sourceforge.net/2005-ols/2005-ext3-paper.pdf] | ||
+ | [http://lwn.net/Articles/187321/] |
Revision as of 17:09, 1 April 2008
Design for ext4
- Ext3: default filesystem for many users, reputation of dependability & compatibility, leave existing ext3 users undisturbed, stable
- Scaling up to support large filesystems: Storage advancements, Increasing data storage requirements, only large filesystem users move to ext4
- Features requiring on-disk format change: nanosec timestamps, fast extent allocation, preallocation
- Reliability wrt on-disk corruption
- 64 bit JBD split
- Forward compatibility/upgradeability
- Multiblock allocation
- Delayed allocation
Ext4 Extents
The core of the Ext4 FS is the support for extents. An extent is simply a set of blocks which are logically contiguous within the file and also on the underlying block device. Most contemporary filesystems put considerable effort into allocating contiguous blocks for files as a way of making I/O operations faster, so blocks which are logically contiguous within the file often are also contiguous on-disk. As a result, storing the file structure as extents should result in significant compression of the file's metadata, since a single extent can replace a large number of block pointers. The reduction in metadata should enable faster access as well.
On-Disk Structures
/* * This is the extent on-disk structure. * It's used at the bottom of the tree. */ struct ext4_extent { __le32 ee_block; /* first logical block extent covers */ __le16 ee_len; /* number of blocks covered by extent */ __le16 ee_start_hi; /* high 16 bits of physical block */ __le32 ee_start_lo; /* low 32 bits of physical block */ }; /* * This is index on-disk structure. * It's used at all the levels except the bottom. */ struct ext4_extent_idx { __le32 ei_block; /* index covers logical blocks from 'block' */ __le32 ei_leaf_lo; /* pointer to the physical block of the next * * level. leaf or next index could be there */ __le16 ei_leaf_hi; /* high 16 bits of physical block */ __u16 ei_unused; };