Ext2/3/4 Filesystem
The Extended Filesystem is popular in distributions of the linux kernel where it was created as an extension to the Minix filesystem. Most BSD variants have at least some support for it and there are fuse userland drivers as well. This page serves to keep some notes related to FreeBSD's kernel implementation that supports the original ext2 and sufficient features to support newer versions of the popular filesystem.
The Extended Filesystem was designed, with much inspiration on UFS, to replace the MINIX filesystem used in early versions of Linux. The filesystem is known to be very fast and continues to be very popular despite the availability of other interesting filesystems in linux.
In general Ext2fs is very similar to UFS but lacks support for fragments and, as a consequence, using bigger blocksizes therefore penalizing the wasted space and sometimes making fragmentation a problem. The Linux developers have opted for supporting the faster async mode and compensate the eventual risks with more robust filechecking tools (fsck). In later releases ext2 developers have tried to counter the weaknesses of the filesystem by adding new features in ext3 (journaling) and ext4 (extents) but the basic design seems to have been exhausted and its designers are apparently considering more recent designs as in btrfs. For FreeBSD, supporting ext2fs and it variants is still important for interoperability and as a general experimentation tool.
The initial FreeBSD ext2fs implementation was based on the BSD Lites version by Godmar Back. The initial approach was to reuse the BSD interfaces and the similarities between UFS and ext2 and merge the specific block management routines from Linux. NetBSD did a complete reimplementation from UFS sources.
While on NetBSD the ext2fs implementation shares code with UFS, in FreeBSD the code is independent and has it's own sys/fs/ext2fs area in the kernel. Opengrok is a great tool to study the code.
Coding guidelines
As with the rest of the FreeBSD kernel code, we follow style(9). Where possible we do try to keep the code in sync with UFS/FFS to ensure new UFS fixes and features can be applied to Ext2. When implementing new features it is important to give a thought on the layout: the preference should always be to avoid invasive changes in the files that are shared to some extent with UFS and add new functionality in new files.
The Linux driver is, of course, copyleft, so code cannot be generally copied from one implementation to the other. Luckily our implementation is completely different and much more similar to UFS but for FreeBSD's specific ext2fs driver the general documentation for UFS is useful: as with UFS/FFS, the filesystem interacts heavily with the vnode interface and the name cache.
Features
In FreeBSD ext2, ext3 and ext4 are not different filesystems: ext2 is the base filesystem and some features from ext3 and ext4 are supported. All features in FreeBSD's implementation follow UFS semantics and this can sometimes impose important differences.
- All supported FreeBSD versions support ext2/3/4 read and write with most of the features, except for journaling.
- FreeBSD 13-current supports Big Endian Platforms, including PowerPC, through byteswapping.
- FreeBSD 12.1 and later have support for DTrace to enable debugging in production.
- FreeBSD 12+ includes initial support for writing ext4 filesystems (thanks to Fedor Uporov).
- FreeBSD 10.1-12 used by default reallocblk. This comes from UFS and helps preventing defragmentation issues. Linux doesn't have an exact equivalent but Ext4 does delayed allocation which is similar in concept. In freeBSD 12 the feature was disabled by default as it proved to be unstable.
- FreeBSD 9.x+ fully supports the async mode, which is the default on Linux. Unlike Linux, the default is to use the sync mode which will make your filesystem more reliable at the cost of some performance.
Main developments
During a long time, NetBSD's and FreeBSD's implementations were maintained independently with the main differences being the cleaner license in NetBSD's implementation and the relatively better performance of FreeBSD's implementation. In both cases, running the BSD implementations in async mode (the default in Linux) was considerably slower compared to the Linux implementation.
On year 2025, there has been a Google SoC project (WIP):
Implement Journaling for FreeBSD's Ext3/4
The project successfully made an initial implementation of journaling for ext3 that is still under testing. For ext4 this still requires more work as it has to consider the case for 64 bit support, hooks for the extents calls and journal checksumming.
On year 2009, there was a Google SOC project:
Improving Second Extended File system (ext2fs) and making it GPL free
This merged the block allocation code from NetBSD, removing the code from linux, and a process of merging bugfixes and enhancements from FreeBSD's UFS1 begun. Notably the filesystem was made MPsafe and a feature called "Orlov allocator" (known also as the dirpref changes in UFS circles) were brought in.
Ext2fs development on FreeBSD then became easier thanks to the similarities with the traditional UFS and merging features and fixes from UFS became an ongoing process.
In year 2010, a second Google SoC Project took place:
Enhance ext2fs to support preallocation and read ext4 file systems
Preallocation was implemented but after extensive testing it was determined that block reallocation was a better alternative and was implemented based on UFS code. Read-only support for (extents-based) ext4fs was also developed but was only brought into the tree until 2013. Simultaneously to this project the merging of fixes from UFS1 was finished. This brought basic O_DIRECT support for async mode mounting and several adjustments.
In year 2012, NetBSD has a different Google Summer of Code project:
HTree directory indexing for Ext3
ZhengLiu did a port of Vyacheslav Matyushin's HTree implementation for NetBSD's GSoC. The HTree code in Linux requires some workarounds for the possibility of a hash collision which were not considered for the FreeBSD port. The code was unstable for a while but finally got fixed on SVN r294504.
More recent additions include support for nanosecond/birthtime timestamps (2012), the benefit of a generic SEEK_DATA/SEEK_HOLE lseek() extension (2013), the support for sparse files from ext4 (DamjanJovanovic 2016) and support for Extended Attributes, Ext4 write support, uninit_gb, flex_bg and checksumming (FedorUporov 2017).
Known issues
- We don't support the inline_data feature: it is doable, just no one has done it.
- We support Extended Attributes, but we don't have the calls to support ACLs in a similar way to other BSD filesystems (namely UFS).
- We lack support for journaling which is inconvenient but is not necessarily a problem if you are OK with running in sync mode. Furthermore, at least in the Linux implementation, journaling is known to reduce performance.
- We don't support the SSD trim command: the code to merge this feature from UFS is relatively simple but while on Linux this is a mount option, in FreeBSD's UFS this is set in tunefs. For convenience we always choose to keep the same semantics as in UFS, so it's unsupported (for now).
- Starting from ext2fsprogs v1.43, Linux distributions are activated the 64 bit feature even when partitions are smaller than 16T. This feature caused problems for some Linux bootloaders and utilities. This is supported in FreeBSD as of FreeBSD 12+.
Future Projects
Depending on developer's interest there are some possibilities for future development:
Journaling is a characteristic feature of ext3+. Journaling was a GSoC 2025 project but it still requires work.
- Trim support should be doable, based on the UFS implementation.
Linux's Ext4 has support for encryption.
- Performance testing. Benchmarks against UFS and the original Linux ext2 (or the one in FreeBSD 8.x) are always interesting. We would like to keep the performance as similar as possible to the Linux version but at this time it is not clear how the implementation compares with other implementations.
We currently use the linux ported e2fsprogs but we could bring back the limited but BSD-licensed versions of newfs and fsck from NetBSD or older FreeBSD.
- Perhaps see what would be missing to make ext2 an installation option.
Ext3 Inode Versioning (Lustre): The e2di_version field is unused in FreeBSD; we could support the corresponding ioctl for linux binary applications.
Documentation
Unlike a native filesystem, where one can generally take some liberties with the on-disk structures, the generak format is defined by the linux developers. Developers are encouraged to read the existing (public) documentation before starting to work on new features. The most up to date information for the linux Ext4 implementation is available through the linux kernel project itself:
ext4 Data Structures and Algorithms
Some documentation for the Linux implementation:
Patent: US Patent 20100057755 A1, File system with flexible inode structures. (Red Hat has extended its patent promise to all open-source licenses).
Videos:
NYLUG Presents: Ted Ts'o on the ext4 Filesystem (Jan 10, 2013)
The BSDCan talk in May 2014 gave an overview of the FreeBSD implementation and some approaches considered.