Re: Nanosecond fs timestamp support: sad

[Matt Mackall <mpm@selenic.com>]

On Fri, 2011-07-29 at 21:49 +0200, Pavel Machek wrote:
> Hi!
> 
> > > If not, we probably should tell NFSv4 to use timestamps and focus on making
> > > them work well.
> > > ??
> > > 
> > > The timestamp used doesn't need to update ever nanosecond.  I think if it
> > > were just updated on every userspace->kernel transition  (or effective
> > > equivalents inside kernel threads) that would be enough capture all
> > > causality.  I wonder how that would be achieved..  I wonder if RCU machinery
> > > could help - doesn't it keep track of when threads schedule ... or something?
> > 
> > Sort of.
> > 
> > Some observations:
> > 
> > - we only need to go to higher resolution when two events happen in the
> > same time quantum
> > - this applies at both the level of seconds and jiffies
> > - if the only file touched in a given quantum gets touched ago, we don't
> > need to update its timestamp if stat wasn't also called on it in this
> > quantum
> 
> parse error aroound 'ago'.

This should read:

- if only one file is touched in a given quantum, we don't need to
update its timestamp if stat wasn't called on it in the same quantum

> > - we never need to use a higher resolution than the global
> > min(s_time_gran)
> > 
> > 
> > For instance, if a machine is idle, except for writing to a single file
> > once a second, 1s resolution suffices.
> 
> Are you sure? As soon as you get network communication...

I don't think you can generally compare filesystem timestamps to other
time sources reliably. For instance, network filesystems might have
their own notions of current time.

> > Any time two files are touched in the same second, the second one (and
> > later files) needs jiffies resolution. Similarly, any time two files are
> > touched in the same jiffy, the second one should use gtod().
> 
> For make. I don't see how this is globally true.
> 
> I do
> 
> ( date; > stamp; date ) | ( sleep 5; cat > counterexample )
> 
> I know timestamp should be between two dates, but it is not.

You're claiming the timestamp on 'stamp' should be strictly between the
two dates reported?

This is true today if and only if you measure in seconds (and your
filesystem's clock is synced with your local clock). If you measure in
resolutions greater than the filesystem resolution (currently limited to
jiffies) even on a local filesystem, it will be wrong.

-- 
Mathematics is the supreme nostalgia of our time.