Re: Nanosecond fs timestamp support: sad

[Pavel Machek]

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'.

> - 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...

> 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.

								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/