Page MenuHomeFreeBSD

Defer the January 19, 2038 date limit in UFS1 filesystems to February 7, 2106
AcceptedPublic

Authored by mckusick on Wed, Jan 29, 1:58 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Feb 3, 5:00 PM
Unknown Object (File)
Mon, Feb 3, 11:54 AM
Unknown Object (File)
Mon, Feb 3, 9:15 AM
Unknown Object (File)
Mon, Feb 3, 8:00 AM
Unknown Object (File)
Mon, Feb 3, 2:41 AM
Subscribers

Details

Reviewers
kib
chs
ziaee
Summary

UFS1 uses signed 32-bit values for its times. Zero is January 1, 1970 UTC. Negative values of 32-bit time predate January 1, 1970 back to December 13, 1901. The maximum positive value for 32-bit time is on January 19, 2038 (my 84th birthday). On that date, time will go negative and start registering from December 13, 1901. Note that this issue only affects UFS1 filesystems since UFS2 has 64-bit times. This fix changes UFS1 times from signed to unsigned 32-bit values. With this change it will no longer be possible to represent time from before January 1, 1970, but it will accurately track time until February 7, 2106. Hopefully there will not be any FreeBSD systems using UFS1 still in existence by that time (and by then I will have been dead long enough that no-one will know at whom to yell :-).

It is possible that some existing UFS1 systems will have set times predating January 1, 1970. With this commit they will appear as later than the current time. This commit checks inode times when they are read into memory and if they are greater than the current time resets them to the current time. By default this reset happens silently, but setting the sysctl vfs.ffs.prttimechgs=1 will cause console messages to be printed whenever a future time is changed.

Test Plan

Have Peter Holm run his suite of filesystem tests.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Great-grandmaster mckuscik,
Would you be willing to put vfs.ffs.prttimechgs in ffs(4) in this commit?
Huge fan of your work, and setting a good example of passion for next generations.
Sincerely,
Alex

sys/ufs/ffs/ffs_subr.c
423

and then de-indent the rest of the function

sys/ufs/ffs/ffs_vfsops.c
228

Why do we need to fix UFS2 inode's times? (and the call should be nop anyway due to check for UFS1 inside the function)

I will follow up these comments with a new set of diffs reflecting suggested changes.

sys/ufs/ffs/ffs_subr.c
423

All the ffs_oldfscompat_* functions are always called for all filesystem types. At first, they all were only needed for UFS1 filesystems but over time UFS2 needed them too. For example, if a UFS3 gets added there is a good chance that UFS2 filesystems will need some compatibility code. This code should be able to be added without having to find places that might need to start calling this function. In my update, I will rewrite it as a case statment to make it clear that it will work for changes to UFS2 inodes.

sys/ufs/ffs/ffs_vfsops.c
228

At this time there are no changes needed for UFS2 inodes. But at some future time there may be some change that needs to be done for UFS2 inodes. So, I want to ensure that the function will be called whenever any UFS inode is loaded.

Updates to respond to reviewer feedback,

This revision is now accepted and ready to land.Thu, Jan 30, 10:55 PM
share/man/man4/ffs.4
292

Thanks for putting this in! I think there's an extra El in there.

share/man/man4/ffs.4
292

Good catch. I'll fix it before checking it in.