== Checking what features your ext4 filesystems have 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 ModernPartitionSizesQuestion]]. 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 ExtNDumpDeprecated]]. 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 Ext3ToExt4Limitation]]. 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 https://man7.org/linux/man-pages/man8/dumpe2fs.8.html]] -h_' or '_[[tune2fs https://man7.org/linux/man-pages/man8/tune2fs.8.html]] -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: .pn prewrap on > 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_ https://man7.org/linux/man-pages/man5/mke2fs.conf.5.html]]. 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)_ https://man7.org/linux/man-pages/man5/ext4.5.html]]. 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 https://wiki.archlinux.org/title/ext4#Enabling_metadata_checksums_in_existing_filesystems]], if I want to (see also [[the ext4 wiki entry https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums]]). 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.)