Noticed while writing a patch to grab time from the ZFS uberblock so
that ZFS rootfs systems without an RTC can have a reasonable starting
time: upon importing the pool, it will (always?) update the uberblock
in-memory immediately and grab a bogus timestamp of 1 because the
kernel clock isn't set yet. I haven't followed through ZFS enough to
understand the ramifications, but if this uberblock gets persisted to
disk then it will be subsequently ignored because it looks very old,
which seems like a good opportunity to lose some writes if we panic
early on.
Move the RTC-read earlier to avoid the problem entirely using the new
inittodr_{early,late} split.
ZFS should likely also avoid stamping a time earlier than the current
ub_timestamp as a defense mechanism and for systems without an RTC in
particular, but we can at least ensure that it gets a valid timestamp
for systems that *do* have an RTC.
I haven't spent any time looking at whether UFS/FFS might do something
similar, or if the clock isn't relevant until a write occurs later.