Re: i386/RTC: old problem, new solution?

[Richard Gooch]

Rafael Reilova writes:
> On Fri, 21 May 1999, Richard Gooch wrote:
> > The only place I'm aware that the kernel needs to know the timezone is
> > this case with suspend/resume. So aside from this, I don't see a need
> > for the kernel to know the timezone. Hm. Although I vaguely remember
> 
> The other case which has been claimed is to set the mount/fsck timestamps
> on the filesystems at boot, but it is mostly a special case, ie,
> 
> 1. kernel boots (RTC is non-UTC) and has no idea of the timezone
> 2. root filesystem is monted read-only
> (2.5). run fsck on / (this is the catch, see below)
> 3. hwclock is run from the boot scripts, kernel now knows correct time
> 4. remount / rw
> 5. mount/fsck/etc proceed as usual with the right time.
>
> Now if the root filesystem is corrupted, then after fsck is run,
> time will probably be messed up in it, but that is an abnormal
> condition.  The other posibility is to run hwclock before fsck, but
> that is not safe.  If you have everything in a single partition then
> that's another story ;-)

What's unsafe about running hwclock before fsck? Since root is mounted
ro, what damage can be done?

> IMHO, a simple command parameter giving the offset in hours
> (half-hours?)  from UTC to the kernel is fine, but I really hope
> nobody is considering adding daylight savings, leap seconds, and all
> that userland craziness to the kernel 8)

At most half-hours (Adelaide, South Australia has a half-hour
timezone). But I think this is a bad idea. I remember all the trouble
we had with our Convex C220 where the OS and the SPU (Service
Processor Unit, pronounced "spew") each had their own timezone. It
caused no end of trouble. Admittedly it was because there was an
inconsistency in their timezone tables, but I still think it's a bad
idea.

Duplication of data is inherently fragile. It's to be avoided if at
all possible. The fsck case doesn't seem to justify the risk.

				Regards,

					Richard....