On Tue, Nov 12, 2019 at 01:09:09PM +0100, Arnd Bergmann wrote: > XFS is the only major file system that lacks timestamps beyond year 2038, > and is already being deployed in systems that may have to be supported > beyond that time. > > Fortunately, the inode format still has a few reserved bits that can be > used to extend the current format. There are two bits in the nanosecond > portion that could be used in the same way that ext4 does, extending > the timestamps until year 2378, as well as 12 unused bytes after the > already allocated fields. > > There are four timestamps that need to be extended, so using four > bytes out of the reserved space gets us all the way until year 36676, > by extending the current 1902-2036 with another 255 epochs, which > seems to be a reasonable range. > > I am not sure whether this change to the inode format requires a > new version for the inode. All existing file system images remain > compatible, while mounting a file systems with extended timestamps > beyond 2038 would report that timestamp incorrectly in the 1902 > through 2038 range, matching the traditional Linux behavior of > wrapping timestamps. > > Signed-off-by: Arnd Bergmann <a...@arndb.de>
This is basically what I proposed ~5 years or so ago and posted a patch to implement it in an early y2038 discussion with you. I jsut mentioned that very patch in my reposnse to Amir's timestamp extension patchset, pointing out that this isn't the way we want to proceed with >y2038 on-disk support. https://lore.kernel.org/linux-xfs/20191112161242.ga19...@infradead.org/T/#maf6b2719ed561cc2865cc5e7eb82df206b971261 I'd suggest taking the discussion there.... Cheers, Dave. -- Dave Chinner da...@fromorbit.com _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
