Checking what features your ext4 filesystems have

December 30, 2021

I have new disks for my home desktop that are going to be used for the root filesystem (and a ZFS pool), once I decide on partition sizes. Since I have my existing root partition in a software RAID, there are two ways to move over to using the new disks. First, I can add the new disks as additional mirrors to the software RAID and let software RAID resync do a transparent copy and eventual migration, or I can make a new software RAID mirror, mkfs a new ext4 filesystem in it, and then copy my existing root filesystem over.

(In the past I would have used the venerable dump and restore for this, but they're now deprecated. I could use tar or rsync, and I'm not certain which is better.)

One advantage of making a new ext4 filesystem and copying things over is that it would have all of the latest ext4 features and recommended settings. If your extN filesystem is sufficiently old, it can have old settings that limit what you can do with it, as I found out when I considered converting my ext3 filesystems to ext4. My existing root filesystem is not all that new, so I wanted to at least look into what features it had and might be missing.

To see what features and settings an extN filesystem has, you use either 'dumpe2fs -h' or 'tune2fs -l' on the filesystem's block device, which in my case is /dev/md10. Currently, the only difference between the two is that dumpe2fs will report some additional information about the journal. As far as I know, the bits of the output that you care about are:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
[...]
Inode size:               256

(You may also care about the filesystem's creation time, which in my case is 'Sun Feb 19 20:28:20 2017'. This isn't quite as old as I expected.)

Unfortunately this will not tell you what features your ext4 filesystem is missing. For that, you need to figure out what features a new ext4 filesystem would be created with. This is generally set in /etc/mke2fs.conf. On Fedora 34 (I still haven't upgraded to Fedora 35), this has:

[defaults]
  base_features = sparse_super, large_file, filetype, resize_inode, dir_index, ext_attr
[....]
[fs_types]
  ext4 = {
    features = has_journal, extent, huge_file, flex_bg, metadata_csum, 64bit, dir_nlink, extra_isize
    inode_size = 256
  }

(Without spaces after the commas; I added them to avoid giant long lines in this entry.)

The meaning of the features themselves are documented in ext4(5).

A careful cross-examination of my mke2fs and the features in tune2fs's output shows that the only feature I'm missing is metadata_csum, and I am using 256 byte inodes (which is required to support dates after January 19th, 2038). According to the Arch Wiki, metadata checksums can be enabled on existing ext4 filesystems, if I want to (see also the ext4 wiki entry). This means that I probably don't want to bother creating a new root filesystem and copying everything over, since it's more work for little gain.

(I'm not even sure that I want to enable metadata checksums for my root filesystem. In any case it doesn't seem critical, since almost all data in the root filesystem is covered by RPM file checksums, and as far as I know ext4 can't reissue a read request to the other side of a software RAID mirror if it detects a checksum error the way ZFS can.)

Written on 30 December 2021.
« Pipx's 'reinstall' command works right by reinstalling injected packages too
Why I (still) use ext4 for my Linux root filesystems »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Dec 30 23:53:09 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.