Overview

e2fsprogs is the userspace half of ext2, ext3 and ext4: mke2fs to create a file system, e2fsck to check and repair one, plus resize2fs, e2image and a handful of others. Most of them are built on the shared libext2fs library, so work done there tends to show up in several tools at once.

I contributed features and fixes across many releases, and maintained the e2fsprogs package for Red Hat Enterprise Linux and Fedora while I was there. I stopped maintaining it when I left Red Hat.

75 commits · 4,483 insertions(+) · 713 deletions(-)

Notable highlights

Discard support in mke2fs and e2fsck

Devices that support TRIM/UNMAP/WRITE_SAME/ERASE reclaim space and manage wear leveling better when the file system tells them which blocks it no longer needs. Both mke2fs and e2fsck know exactly that, and they know it at a moment when nothing else is using the device.

I added discard support to libext2fs and wired it into both tools. mke2fs discards the device before it creates the file system. e2fsck discards free blocks and unused inodes in pass 5, where the bitmaps have just been verified as correct, which is the one point in the run where you can trust them. Both take discard and nodiscard. If the device does not support discard, or returns an error, e2fsck stops trying and carries on as though nodiscard had been given.

Red-black tree bitmaps in libext2fs

e2fsck stored its metadata bitmaps as bit arrays, which is the obvious representation and was fine for a long time. The problem is that a bit array allocates memory for the whole range, including the large parts of it that are never used. On a multi-terabyte file system those bitmaps can run to gigabytes.

I added a second backend to libext2fs that stores bitmaps as extents in a red-black tree, so only the used ranges cost anything. On a 312 GB file system aged with Impression it used roughly 65% less memory than the bit array.

That number is not a promise. It grows with file system size, and it can go the other way, even turn negative, when the inodes are fragmented badly enough that the tree ends up holding a large number of tiny extents.

QCOW2 support in e2image

e2image writes out a file system’s metadata for offline analysis and recovery. It could already produce sparse images, which are small on disk, right up until somebody copies one with a tool that does not understand sparse files and the full size comes back.

I added QCOW2 output, under -Q. A QCOW2 image is not sparse. It is compact by construction, so it stays small no matter what copies it, and e2image -r converts one back to raw.

There is one caveat worth stating plainly: the conversion path makes assumptions that hold for images e2image produced and may not hold for arbitrary QCOW2 files, so do not point it at one. The other direction is fine. The images it writes are ordinary QCOW2, and qemu-img and qemu-nbd read them without complaint.

Bug fixes and incremental improvements

Most of my e2fsprogs commits are diagnostics, bug fixes and usability work spread across the tools, and a good share of them came out of maintaining the package for RHEL and Fedora, where new kernel features, distribution integration testing and users doing unexpected things surface problems that upstream testing did not.