Y2K38 filesystems

This is a small note...

This happens to me some times. I mount a filesystem and I get the warning:

xfs filesystem being mounted at /mntimg supports timestamps until 2038-01-19 (0x7fffffff)

This has to do with the year 2038 problem.

Background

The year 2038 problem (also known as Y2038, Y2K38, Y2K38 superbug or the Epochalypse) is a time computing problem that leaves some computer systems unable to represent times after 03:14:07 UTC on 19 January 2038.

The problem exists in systems which measure Unix time -- the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1970) -- and store it in a signed 32-bit integer. The data type is only capable of representing integers between -(2³¹) and 2³¹ − 1, meaning the latest time that can be properly encoded is 2³¹ − 1 seconds after epoch (03:14:07 UTC on 19 January 2038). Attempting to increment to the following second (03:14:08) will cause the integer to overflow, setting its value to -(2³¹) which systems will interpret as 2³¹ seconds before epoch (20:45:52 UTC on 13 December 1901). The problem is similar in nature to the year 2000 problem, the difference being the Year 2000 problem had to do with base 10 numbers, whereas the Year 2038 problem involves base 2 numbers.

See wikipedia article

What to do

Of course, you can just ignore it, it is merely a warning and not an error. If you want to keep your logs clean of these, you can update your filesystems or just create new ones. Ironically, this only affects UNIX style filesystems such as xfs and ext4. It does not affect other filesystems like vfat used by MSDOS.

For xfs and ext4, the Linux Kernel introduced patches back in version 5.10 circa 2021 to address these.

xfs

For xfs, when you createa new file system it should default now to using 64 bit timestamps. Otherwise you can force it with this command:

mkfs.xfs -m bigtime=1 device

If you have existing file systems you can convert them with this process:

1. Run xfs_repair -n to make sure that there are no errors
2. Run:

   xfs_amdin -O bigtime=1 device

ext4

Check if the filesystem needs to be upgraded:

$ tune2fs -l device | grep "Inode size:" Inode size: 128

Where an inode size of 128 is insufficient beyond 2038 and an inode size of 256 is what you want.

Current version of mkfs will create a filesystem with the appropriate inode size. Otherwise, you can use the command with the right inode size:

mkfs.ext4 -I 256 device

Unfortunately, there is no safe way to change an existing filesystem. The current version of e2fsprogs does accept a -I 256 option, however, the functionality is disabled when flex_bg (which is on by default) is enabled. But even making sure that flex_bg is off, resizing the inodes fails.

The best way to do the conversion is then to:

1. backup filesystem
2. re-create filesystem
3. restore backup