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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
