lkml.org 
[lkml]   [2001]   [Oct]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 13 Oct 2001 21:38:20 +0200
FromJamie Lokier <>
SubjectRe: Finegrained a/c/mtime was Re: Directory notification problem
Andi Kleen wrote:
> > Andi Kleen says we can ignore the risk; I disagree, as there are some
> > applications that cannot be trusted if the risk is plausible, and it can
> > be fixed easily.
> 
> You're misquoting me badly.  I said we can ignore the risk that two
> nanosecond resolution timestamps that get changed by two different cpus 
> with out-of-sync cycle counter on a smp system and which are fast enough
> to free/aquire the inode lock in a smaller time than they're out of sync
> (= giving two file changes with the same ns timestamp) can be ignored.
> I implied on the systems that don't have a cycle counter and which use
> jiffie resolution gettimeofday it can be also ignored, because they're
> unlikely to be SMP and dying out too anyways. 

Andi, sorry I misrepresented your statement.

I misread your original as saying that the risks due to SMP nanosecond
scale synchronisation problems can be ignored.  Implied from that, that
the small risk of one SMP process modifying a file while another checks
the timestamp can be ignored.  I misread this way because others have
suggested higher resolution solves the problem, and I believe it does not.

As you say above, multiple modifications within a single tick are not a
problem, do not have to be tracked, and therefore do not require SMP
sychronisation.

The SMP risk of missing a change after checking the timestamp is among
the risks I consider critical for an application which must not miss the
fact that a file has changed.  I do not want us to repeat the mistake of
1 second at a smaller timescale.

cheers,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:08    [from the cache]
©2003-2008