Messages in this thread | | | Subject | Re: [PATCH 01/11] x86: Fix vtime/file timestamp inconsistencies | From | john stultz <> | Date | Wed, 14 Jul 2010 09:19:04 -0700 |
| |
On Wed, 2010-07-14 at 11:40 +0900, KOSAKI Motohiro wrote: > Hi > > > Due to vtime calling vgettimeofday(), its possible that an application > > could call time();create("stuff",O_RDRW); only to see the file's > > creation timestamp to be before the value returned by time. > > Just dumb question. > > Almost application are using gettimeofday() instead time(). It mean > your fix don't solve almost application.
Correct, filesystem timestamps and gettimeofday can still seem inconsistently ordered. But that is expected.
Because of granularity differences (one interface is only tick resolution, the other is clocksource resolution), we can't interleave the two interfaces (time and gettimeofday, respectively) and expect to get ordered results.
This is why the fix I'm proposing is important: Filesystem timestamps have always been tick granular, so when vtime() was made clocksource granular (by using vgettime internally) we broke the historic expectation that the time() interface could be interleaved with filesystem operations.
Side note: For full nanosecond resolution of the tick-granular timestamps, check out the clock_gettime(CLOCK_REALTIME_COARSE, ...) interface.
> So, Why can't we fix vgettimeofday() vs create() inconsistency? > This is just question, I don't intend to disagree you.
The only way to make gettimeofday and create consistent is to use gettimeofday clocksource resolution timestamps for files. This however would potentially cause a large performance hit, since each every file timestamp would require a possibly expensive read of the clocksource.
thanks -john
| |