missing y2038 support

Posted Mar 7, 2022 21:11 UTC (Mon) by arnd (subscriber, #8866)
Parent article: When and why to deprecate filesystems

While this sounds like as good an excuse for removing file systems as any other, I don't think this should be the main reason. Half the file system implementations we have by now only exist in order to access old disk images, and this works regardless of whether one is able to create new files or not. We originally had a patch to refuse writable mounts on file systems that have known y2038 bugs, making those images read-only, but that got Nack'ed and we ended up with just a warning printed to the console.

Side note: reiserfs doesn't actually have a y2038 problem at all, it uses unsigned 32-bit timestamps with a range from 1970 to 2106. https://kernelnewbies.org/y2038/vfs lists the limits, I think only ext2/ext3, coda, exofs, hostfs, and ufs1 still have the y2038 problem, and a few others have been changed to interpret the seconds as unsigned.

missing y2038 support

Posted Mar 8, 2022 2:02 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

A disk image is just a very elaborate archive format. I'm 85% sure that, if someone is really using it, then userspace tools will exist or be created, regardless of whether the kernel supports it or not.

missing y2038 support

Posted Mar 8, 2022 8:03 UTC (Tue) by pm215 (subscriber, #98099) [Link] (5 responses)

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.

missing y2038 support

Posted Mar 10, 2022 17:42 UTC (Thu) by jccleaver (guest, #127418) [Link]

> We originally had a patch to refuse writable mounts on file systems that have known y2038 bugs, making those images read-only, but that got Nack'ed and we ended up with just a warning printed to the console.

This really seems like something to bubble back up, at least in preparation for the actual post-2038 strategy. I can't think of a better solution for how to properly handle something that is perfectly readable fine but which has no way to encode properly-readable vital (i.e. security) metadata about an operation.

Just leave this feature flag disabled for now, and builders can enable it as desired; with a full flip in the years to come.