Filesystem timestamps

A 64-bit time_t in RAM does not enlarge a 32-bit field in an inode. Filesystems are their own deadline table.

Filesystem	Default ceiling	Extended ceiling
ext2 / ext3	2038	None in the classic layout
ext4, 128-byte inodes	2038	Need larger inodes for extra epoch bits
ext4, 256-byte inodes	~2446	Two extra epoch bits stolen from nanoseconds
XFS without bigtime	2038	Kernel warns at mount
XFS with bigtime (Linux 5.10+)	2486	`mkfs.xfs -m bigtime=1` or `xfs_admin -O bigtime=1`
NTFS	year 60056	Different epoch (1601)
Btrfs	64-bit times	Not a time32 format

How to see it

tune2fs -l /dev/sdXn | grep -i inode
xfs_info /mountpoint
dmesg | grep -i 'timestamps until'

RHEL 9 enables XFS bigtime by default on new filesystems; those volumes will not mount on RHEL 8. That compatibility trap is more likely to bite administrators in the 2020s than the overflow itself.

ext4 inode size is the real switch

Classic ext2/ext3 and ext4 file systems created with 128-byte inodes store timestamps in 32-bit seconds. They hit 19 January 2038. Default mkfs.ext4 on modern e2fsprogs uses 256-byte inodes, which steal two extra epoch bits from the nanosecond fields and reach about year 2446.

tune2fs -l /dev/sdXn | grep -E 'Inode size|Filesystem features'
# Inode size: 256  → extra epoch bits available
# Inode size: 128  → time32 on disk, even on a 64-bit kernel

You cannot raise inode size on a live filesystem. The practical options are migrate to a new volume, or accept that that disk format is a 2038 problem regardless of the OS.

XFS bigtime

XFS without bigtime is a 2038 format. Linux 5.10 added the feature; new RHEL 9 / recent mkfs.xfs volumes enable it by default and then will not mount on older kernels.

xfs_info /mount | grep bigtime
# enable on an existing unmounted volume (backup first):
# xfs_admin -O bigtime=1 /dev/sdXn