On Nov 27, 2012, at 9:03 AM, Sage Weil <s...@inktank.com> wrote: > On Tue, 27 Nov 2012, Sam Lang wrote: > >> 3. When a client acquires the cap for a file, have the mds provide its >> current >> time as well. As the client updates the mtime, it uses the timestamp >> provided >> by the mds and the time since the cap was acquired. >> Except for the skew caused by the message latency, this approach allows the >> mtime to be based off the mds time, so it will be consistent across clients >> and the mds. It does however, allow a client to set an mtime to the future >> (based off of its local time), which might be undesirable, but that is more >> like how NFS behaves. Message latency probably won't be much of an issue >> either, as the granularity of mtime is a second. Also, the client can set its >> cap acquired timestamp to the time at which the cap was requested, ensuring >> that the relative increment includes the round trip latency so that the mtime >> will always be set further ahead. Of course, this approach would be a lot >> more >> intrusive to implement. :-) > > Yeah, I'm less excited about this one. > > I think that giving consistent behavior from a single client despite clock > skew is a good goal. That will make things like pjd's test behave > consistently, for example. >
My suggestion is that a client writing to a file will try to use it's local clock unless it would cause the mtime to go backward. In that case it will simply perform the minimum mtime advance possible (1 second?). This handles the case in which one client created a file using his clock (per previous suggested change), then another client writes with a clock that is behind. David -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
