Konrad Schroder wrote:

> [[ cvs commit details for lfs_cleanerd deleted ]]
> 
> If "time"
> is not monotonically increasing (e.g. clock is slaved to another system)
> the optimization will result in segments being treated as corrupt
> (uncleanable).

I've wondered about this once or twice in the past.  At a quick glance,
it looks like we don't have a monotonic time source in the kernel that
won't wrap around.  ticks (in kern_clock.c) comes close, but on a 1024Hz
32 bit machine it wraps around every 24ish days...  This monotonic value
could be returned to userland with somethink like Solaris' gethrtime().

At the easiest level, just having a u_int64_t that gets incremeneted
by the number of nanoseconds (to be compatible the gethrtime()) per
clocktick in hardclock() would be the easy way out.  This obviously
isn't good enough for those machines that have access to a high
resolution timer - maybe having an MD function that returns the number
of nanoseconds since the last clock interrupt would be the way to go.

Is this worth thinking about more, or should I just drop it?

Simon.