ms 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).
> 
> 
> We likely should do it both times. If it fails the first time, we'll call it a second
> time after the mount with the superblock time. How we communicate time
> that we think is approximately good or not...
> 
>     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.
> 
> 
> Yes. I agree this is a good approach, but how does the rootfs code know that
> the time is bogus and shouldn't be trusted. And how do they find out later once
> time is believed to be good (ntpd, ad-hoc early-in-boot programs, etc).
> 

That, I don't really know.  One proposal I had for ZFS is that it shouldn't let the
uberblock timestamps go backwards, or at least beyond a certain threshold -- if it
tries to, we could just bump the timestamp by 1 from the recorded time so that our new
uberblock is preferred and move on, knowing that inittodr() would likely prefer the
notion of time we provide that was on disk.  Any timestamps we try to pull from mountroot
to ntpd/chrony/etc. would still be bogus, but a lot better than they are today for
these systems.

Having written that out, I think it's worth looking closer at that ub update and whether
it gets persisted to disk.  I'm specifically wondering if it's possible that we could
needlessly lose writes as a consequence after an unclean shutdown even on systems with
an RTC, since the clock isn't setup until after.

Thanks,

Kyle Evans