Re: git: a64877b140fe - stable/15 - Avoid incorrect UFS1 timestamp corrections when system clock fails at boot.

On 6/9/26 16:27, Kirk McKusick wrote:
> The branch stable/15 has been updated by mckusick:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=a64877b140fe0bf374cc96c95f374894c1627a32
> 
> commit a64877b140fe0bf374cc96c95f374894c1627a32
> Author:     Kirk McKusick <mckusick@FreeBSD.org>
> AuthorDate: 2026-06-01 23:48:21 +0000
> Commit:     Kirk McKusick <mckusick@FreeBSD.org>
> CommitDate: 2026-06-09 21:26:51 +0000
> 
>      Avoid incorrect UFS1 timestamp corrections when system clock fails at boot.
>      
>      Git 1111a44301da - main - Defer the January 19, 2038 date limit in
>      UFS1 file systems to February 7, 2106 - did so by changing the UFS1
>      32-bit signed timestamps to unsigned. With this change, time stamps
>      from before January 1, 1970 went from being negative numbers to
>      large positive numbers implying times in the future. When such a
>      time stamp is encountered when an inode is read into memory or when
>      it is encountered by fsck, its timestamp is replaced with the
>      kernel's current time.
>      
>      Andre Albsmeier reported that he had a machine reboot after a power
>      failure and the battery that maintained its real-time clock had
>      died. The result was that the system booted with the time set to
>      five years earlier (absent a real-time clock value, the boot ROM
>      used the time that the boot ROM had last been updated). The net
>      result was that fsck reset the time stamps of all files newer than
>      five years old to the five year old time.
>      
>      Andres's original request was for a flag in the file system superblock
>      to say that there are no timestamps from before 1970 in the file
>      system, so there shouldn't be anything to fix because of the signed
>      to unsigned switch. But this assumes that no one every does an rsync
>      or extracts a tar file or restores a dump that introduces an incorrect
>      time stamp on their system. So this approach was not taken.
>      
>      This change compares the system's version of the current time to
>      the last modification time in the file system superblock. If the
>      current time is earlier than that time then use the last modification
>      time in the superblock as the value for the current time. There
>      should be no files in the file system with times newer than the
>      last modification time in the superblock.
>      
>      The superblock time stamp is updated in the in-memory superblock
>      every time any change is made to anything in the file system. The
>      superblock is written to the disk every 30 seconds, so it may be
>      off by up to 30 seconds plus the time it sits in the disk cache
>      waiting to be written if the system has an unclean shutdown (such
>      as a power failure). Thus, the worst case scenario with this change
>      is that files written in the last 30 seconds plus disk cache delay
>      time before the crash may have their times adjusted back by up to
>      30 seconds plus the disk cache delay time.
>      
I have a related question that came up while I was working on a patch for
ZFS[0] to set a mount-time for those of us with broken RTCs.  The current
version of mountroot[1] calls inittodr() *after* the root is mounted, which
means that anything needing to pull a timestamp when the root is mounted
gets a time <= 10 (probably 1).

In ZFS, this results in an uberblock update that leaves a bogus timestamp
around until another update occurs, and I'm not sure that that's really OK.
I'm wondering if we should consider splitting inittodr() or something to
try and read the RTC before we have a root, and 'fixing' the clock after root
is mounted if we need a hint from the rootfs?  I don't know if any of this
matters for UFS.

Thanks,

Kyle Evans

[0] https://github.com/openzfs/zfs/pull/18645
[1] https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c?id=01c8e2e33df81b242d73a23de49a6b61f33c24c1#n1105