Messages in this thread | | | Date | Fri, 29 Jul 2011 21:49:03 +0200 | From | Pavel Machek <> | Subject | Re: Nanosecond fs timestamp support: sad |
| |
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
| |