Re: Finegrained a/c/mtime was Re: Directory notification problem

[Padraig Brady <padraig@antefacto.com>]

Andi Kleen wrote:

>On Fri, Oct 05, 2001 at 01:44:20PM +0100, Padraig Brady wrote:
>
>>Andi Kleen wrote:
>>
>>>On Wed, Oct 03, 2001 at 11:15:04AM -0400, Alex Larsson wrote:
>>>
>>>>Is a nanoseconds field the right choice though? In reality you might not 
>>>>have a nanosecond resolution timer, so you would miss changes that appear
>>>>on shorter timescale than the timer resolution. Wouldn't a generation 
>>>>counter, increased when ctime was updated, be a better solution?
>>>>
>>>Near any CPU has a cycle counter builtin now, which gives you ns like
>>>resolution. In theory you could still get collisions on MP systems, 
>>>but window is small enough that it can be ignored in practice.
>>>
>>>-Andi
>>>
>>But the point is you, only ever would want nano second resolution to make
>>sure you notice all changes to a file. A more general (and much simpler)
>>solution would be to gen_count++ every time a file's modified. What other
>>applications would require better than second resolution on files?
>>
>
>The main advantage of using a real timestamp instead of a generation
>counter is that we would be compatible to Unixware/Solaris/... Their
>API is fine, so I see no advantage in inventing a new incompatible one.
>
Even so I can't see a need to have this resolution for mtime, and as you 
pointed
out there can still be races on SMP systems and timing resolutions are 
system
dependent anyway.

>
>Another advantage of using the real time instead of a counter is that 
>you can easily merge the both values into a single 64bit value and do
>arithmetic on it in user space. With a generation counter you would need 
>to work with number pairs, which is much more complex. 
>
??
if (file->mtime != mtime || file->gen_count != gen_count)
     file_changed=1;

>
>[or alternatively reset the generation counter every second in the kernel
>to get a flat time range again, 
>which would be racy and ugly and complicated in the kernel because it 
>would need additional timestamps] 
>
No need as long as it doesn't wrap within the mtime resolution (1 second).

>
>Also a rdtsc/get_timestamp or in the worst case a jiffie read is really
>not complex to code in kernel, what makes you think it is? 
>
Sorry, by more complex I meant more instructions/CPU expensive.

>
>
>-Andi
>
Padraig.