On Jan 12, 2019, at 2:43 AM, Geert Uytterhoeven wrote: > > Hi Ted, > > I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk > on m68k, containing mid-90's binaries, from right after the a.out-to-ELF > transition, so I notice if someone breaks old syscall support. > > Recently I wanted to change /dev/console on that ramdisk from a symlink > to chardev 5 0. Unfortunately I cannot mount it, without it being > upgraded automatically to a rev 1.0 ext2 filesystem. Apparently the > kernel has been doing that upgrade for ages. > > Do you have a suggestion how to make that change, while preserving the > ext2 revision? It looks like there is a "gratuitous" call to ext4_update_dynamic_rev() in the mount path that is left over from when ext3 always set the INCOMPAT_RECOVER and COMPAT_HAS_JOURNAL features on every mount. With the "nojournal" mount option these are no longer needed. You could probably just remove this call with no ill effects, or better yet apply the patch that I'll push shortly to this effect. It's been there since the start of git history (2.6.12-rc2) in the ext3 code that was later copied to become ext4, but digging through my email archives it looks like adding the call to "ext3_update_fs_rev()" was actually one of my first patches against the original ext3 code "[Ext2-devel] Re: RECOVER INCOMPAT flag", dated Nov 18, 2000. The only thing ext4_update_dynamic_rev() does is update s_rev_level, and set s_first_ino and s_inode_size on disk to the values that the kernel already assumes to be true (newer kernels can use different values). Those fields are also set in memory later during the mount, so the rest of the code should work OK (I haven't tested). This will probably only affect your filesysem (everything else in the last 20 years uses EXT2_DYNAMIC_REV) so it won't be much of a change. The "real" ext2 code looks like it does not call ext2_update_dynamic_rev() for every filesystem during mount, only if you write a file > 2GB in size, so it would also be possible to mount with the ext2.ko driver (if your kernel provides it). There looks like a minor bug in ext2 that it doesn't call ext2_update_dynamic_rev() if an xattr is stored on the filesystem and it sets EXT2_FEATURE_COMPAT_EXT_ATTR in ext2_xattr_update_super_block(). However, nobody noticed in since xattrs landed. In any case, it would be fun to give my patch a try to see if it allows your old filesystem to be mounted and modified with a modern kernel and then mounted on the old kernel again, as a testament to ext2/ext4 feature compatibility. Cheers, Andreas