XFS Patches For Linux 5.10 Delays The Year 2038 Problem To 2486
XFS patches for Linux 5.10 submitted by XFS file system maintainer Darrick J. Wong will delay the year 2038 problem for XFS by an additional 448 years. That should be enough to come up with a real long-term solution. The time-stamp patches were submitted as a part of a larger patch-set with a "large pile of new stuff".
written by 林慧 (Wai Lin) 2020-10-17 - last edited 2020-10-24. © CC BY
Time. It's running out.
The Year 2038 Timestamp Problem is a Linux/Unix problem caused by someone's bright idea to record time elapsed since January 1st 1970 in a 32-bit integer. The Linux kernel itself uses a 64-bit time_t which won't roll over until the year 292,277,026,596. Most of the file-systems in the Linux kernel use their own time-stamps and some of them aren't prepared for 2038.
Deepa Dinamani added a patch that makes file systems show a warning if a file system is doomed in August 2019. This is why you may see messages like:
"ext4 filesystem being mounted at /foo/bar supports timestamps until 2038 (0x7fffffff)"
or
"xfs filesystem being mounted at /foo/bar supports timestamps until 2038 (0x7fffffff)"
in the kernel ring buffer (dmesg) from time to time. It's actually variable in ext4 file systems, those with a inode size of <=128 bytes do not support time-stamps beyond January 2038 and those that are >=256 bytes do. The inode size can be changed with tune2fs -I so any year 2038 problems with ext4 file systems are user-solvable. That's so far not the case with XFS but it may change when Linux 5.10 is released.
Darrick J. Wong sent Linus Torvalds a "large pile of new stuff for 5.10" on Wednesday.
"The biggest changes are two new features for the ondisk metadata: one to record the sizes of the inode btrees in the AG to increase redundancy checks and to improve mount times; and a second new feature to support timestamps until the year 2486."
October 14th, 2020
The code widening the inode time-stamps gives us an additional 448 years to come up with a more long-term solution. It may be of interest that the XFS epoch starts at December 1901, not January 1970 like most other Unix time-stamps.
Another notable change in the patch-set adds inode btree counts to the allocation groups. That speeds up file system mounting and adds a little more metadata redundancy. There's also a mention of fixing "some math errors in the realtime allocator" in the patches comments.
It's not confirmed that the patches will make it into Linux 5.10, but it seems very likely. The merge window is open and Darrick J. Wong, employed by Oracle, is the XFS maintainer so XFS patches from him are merged as a matter of routine.
Enable comment auto-refresher