[lkml]   [2010]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 01/11] x86: Fix vtime/file timestamp inconsistencies
    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, ...)

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


     \ /
      Last update: 2010-07-14 18:21    [W:0.022 / U:10.092 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site