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

[Padraig Brady <padraig@antefacto.com>]

Andi Kleen wrote:

>On Fri, Oct 05, 2001 at 04:00:08PM +0100, Padraig Brady wrote:
>
>>Andi Kleen wrote:
>>
>>>>>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;
>>>>
>>>And how would you implement "newer than" and "older than" with a generation
>>>count that doesn't reset in a always fixed time interval (=requiring
>>>additional timestamps in kernel)?  
>>>
>>>-Andi
>>>
>>Well IMHO "newer than", "older than" applications have until now
>>done with second resolution, and that's all that's required?
>>
>
>No they haven't. GNU make supports nsec mtime on Solaris and apparently
>some other OS too, because the second granuality mtime can be a big 
>problem with make -j<bignumber> on a big SMP box. make has to distingush
>"is older" from "is newer"; "not equal" alone doesn't cut it.
>
>[If you think it is modify your make to replace the "is older" check
>for dependencies with "is not equal" and see what happens]
>

OK agreed, in this case the, complete state/relationship between files, 
must be
maintained independently of the userspace app, i.e. in the filesystem. 
But wont
you then have the same problem with synchronising nanosecond times between
the various processors (which could be the other side of a network cable 
in some
configurations)? So perhaps the best solution is to maintain both a 
generation
count which would do for many apps who just care if the file has changed 
relative
to some moment it time and not relative to another file(s) on the 
filesystem .
Then for make type applications you could maintain the full resolution 
timestamp,
however this will still have the synchronisation/portability/CPU expense 
issues
discussed previously.

Padraig.