Messages in this thread |  | | Date | Fri, 05 Oct 2001 14:15:25 +0100 | From | Padraig Brady <> | Subject | Re: Finegrained a/c/mtime was Re: Directory notification problem |
| |
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.
- 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/
|  |