missing y2038 support

Posted Mar 8, 2022 8:03 UTC (Tue) by pm215 (subscriber, #98099)
In reply to: missing y2038 support by arnd
Parent article: When and why to deprecate filesystems

Looking at that chart, if I have an ext2/3/4[*] file system on disk, is there a command I can use to determine whether it's the ext4-with-new-inodes type or a y2038-problem ext2/ext3/old-ext4 type? And is there a way to in-place convert to the new format, or is it necessary to create a whole new filesystem and copy over all the data ?

[*] I think of all these as basically the same thing, which may or may not be an incorrect mental model, but which I suspect is not an uncommon one...

missing y2038 support

Posted Mar 8, 2022 8:22 UTC (Tue) by TomH (subscriber, #56149) [Link] (3 responses)

Sure, run "dumpe2fs -h <device>" and look at the inode size. It needs to be 256 bytes or larger to support extended timestamps.

You can increase the size with "tune2fs -I <device>" but a fsck needs to be done first so the filesystem will need to be unmounted and you probably want to read what the manual page says before trying it.

missing y2038 support

Posted Mar 8, 2022 9:02 UTC (Tue) by arnd (subscriber, #8866) [Link]

Ah, I did not know that tune2fs could do it, should have read your reply first. However, it seems this does not help with

Changing the inode size not supported for filesystems with the flex_bg feature enabled.

It apparently works on ext4 file systems without the flex_bg feature, and on ext2/ext3 images that do not support flex_bg in the first place, but apparently not on small ext4 images that were created with flex_bg or had it (irreversibly) added later.

missing y2038 support

Posted Mar 8, 2022 17:55 UTC (Tue) by smurf (subscriber, #17840) [Link]

Alternately you can convert the file system to btrfs, in-place.

SCNR …

missing y2038 support

Posted Mar 8, 2022 19:37 UTC (Tue) by pm215 (subscriber, #98099) [Link]

Cheers. Looks like only my /boot filesystems are non-y2038-ready (probably because as Arnd notes else-thread that's still the default for less-than-512MB).

missing y2038 support

Posted Mar 8, 2022 8:48 UTC (Tue) by arnd (subscriber, #8866) [Link]

I don't think you can convert between those in place without a full backup/restore. One way to find out the inode format is to use the "stats" command in debugfs. It appears that at least in e2fsprogs version 1.45.7, the default in mkfs is still to use small inodes for smaller file system images, regardless of the file system type, so an ext2 file system image over 512MB is not actually compatible with the ext2 format unless you manually set the inode size, and smaller ext4 images continue having the y2038 problem:

$ truncate --size=511M ext4.img
$ mkfs -t ext4  -q  ext4.img
$ echo stats | debugfs ext4.img 2>&1 | grep "Inode size"
Inode size:	          128

$ truncate --size=512M ext2.img
$ mkfs -t ext2  -q ext2.img
$ echo stats | debugfs ext2.img 2>&1 | grep "Inode size"
Inode size:	          256

The defaults are configured in /etc/mke2fs.conf, which on my system contains:

        small = {
                inode_size = 128
                inode_ratio = 4096
        }

Removing this bit makes mkfs use 256 byte inodes by default, regardless of the size.