How safe is forward compatibility in EXT4?

Question

I EXT4-formatted a HDD with e2fsprogs 1.45.6-2 on a 64-bit ArchLinux (Kernel 5.4.50) and filled it with data. Afterwards I installed it into a different computer running 32-bit Debian Jessie (Kernel 3.16.84-1) with e2fsprogs 1.42.12-2+deb8u2 and copied a single file to it.

Is this version difference problematic and might have caused damage to the filesystem?

During the shutdown on the 32bit Jessie system I noticed a e2fsck error message, which basically said that it can't run due to metadata_csum.

So I googled and found out that metadata checksums were introduced in 1.43: https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

What makes me feel really uncomfortable is the following quote there... It should NOT be possible for old fs code to write to a filesystem with metadata checksums enabled. The metadata_csum flag is implemented as a ROCOMPAT flag, which should keep (non-malicious) old programs from messing things up.

I was expecting to not be able to mount the filesystem at all if there are any incompatibility issues, but I really fear that I might have messed the FS up.

Any help on this would be much appreciated.

Edit: I used GParted to create the FS and learned in the meantime, that unlike mke2fs it creates filesystems in 32-bit mode by default for drives <16TiB, which is the case for my 8TB drive. I verified this by checking the file systems features provided by tune2fs -l /dev/sda | grep features, which would otherwise include the term '64bit'.

Answer 1

There are two separate compatibility checks; one is by the kernel, and the other is by the e2fsprogs utilities. The 3.16 kernel supports Metadata Checksums, so there was no problem mounting it. However, the version of e2fsprogs in Debian Jessie did not. So, attempts to check the file system using e2fsck failed because the version of e2fsprogs was too old. I'm not sure which program was trying to run e2fsck, but apparently it ignored the exit status from e2fsck, and/or peraps you mounted it manually.

So that explains why you were able to mount the file system even though e2fsck said it couldn't check the file system.

The other caution though is that 3.16 is a very old kernel, and while some bug fixes are backported, not all of them are, and 3.16 stopped getting backports a long, Long, LONG time ago. And, 3.16 was fairly soon after Metadata Checksums were rolled out, and I can't at all guarantee that there aren't any bugs relating to metadata checksums in 3.16.84. But if you only copied a single file to that file system, and the contents of the file checks out, and a modern version of e2fsck doesn't detect any problems, you're probably fine.