Re: CVS commit: src/sys/kern

[Garrett D'Amore <garrett_damore%tadpole.com@localhost>]

Perry E. Metzger wrote:
> Garrett D'Amore <gdamore%netbsd.org@localhost> writes:
>   
>> Module Name: src
>> Committed By:        gdamore
>> Date:                Sun Sep  3 05:25:05 UTC 2006
>>
>> Modified Files:
>>      src/sys/kern: kern_todr.c
>>
>> Log Message:
>> Incorporate changes from x86/i386 as follows:
>>
>> 1) don't set a clock when panicing during early boot
>> 2) if the filesystem time is newer than the rtc time (by at least 2 days) 
>> then
>> revert to the filesystem time.
>>     
>
> Two days is probably too little. One routinely gets situations where
> machines get confused and file system time exceeds RTC time by quite a
> bit.
>
> On the x86 port, we used to use a much larger margin -- years in
> fact. That might be excessive, but two days is too small.
>   

This was discussed with others last night, including Christos and
Gendalia.  The x86 margin was 5 years.  I changed it to use the same 2
days the other ports use.  The 2 days is just a warning.  If the
filesystem time is more than two days out of date, then you probably
haven't been keeping your clock updated (you might have been running
another OS?), and the warning to check your clock is still advisable. 
It doesn't actually _do_ anything, unless the clock gets more than two
days _behind_ your filesystem.

If the clock is more than two days _behind_, then your system clock is
probably busted, and we take corrective action by trusting the
filesystem time.  (Time should always move _forward_, not backwards.)

I recognize these are policy decisions, and I'm happy to adjust.  I'd
_prefer_ to have a single policy that works for all of our ports rather
than different policies for different ports, though.

I definitely think 5 years is _excessive_.  I'd complain if the
difference was more than 6 months.  I suppose what should be considered
is how much a system clock that is unpowered (solely on battery) without
updates is expected to drift, and at what point we should warn admins to
recheck their time.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191