From: Padraig Brady <padraig@antefacto.com>
To: Andi Kleen <ak@suse.de>
Cc: Alex Larsson <alexl@redhat.com>,
Ulrich Drepper <drepper@cygnus.com>,
linux-kernel@vger.kernel.org
Subject: Re: Finegrained a/c/mtime was Re: Directory notification problem
Date: Fri, 05 Oct 2001 13:44:20 +0100 [thread overview]
Message-ID: <3BBDAB24.7000909@antefacto.com> (raw)
In-Reply-To: <m3r8slywp0.fsf@myware.mynet> <Pine.LNX.4.33.0110031111470.29619-100000@devserv.devel.redhat.com> <20011003232609.A11804@gruyere.muc.suse.de>
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?
Padraig.
next prev parent reply other threads:[~2001-10-05 12:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0110022206100.29931-100000@devserv.devel.redhat.com.suse.lists.linux.kernel>
2001-10-03 7:53 ` Finegrained a/c/mtime was Re: Directory notification problem Andi Kleen
2001-10-03 8:06 ` Ulrich Drepper
2001-10-03 13:35 ` Eric W. Biederman
2001-10-03 14:11 ` Netfilter problem Kirill Ratkin
2001-10-03 21:42 ` Luigi Genoni
2001-10-03 15:24 ` Finegrained a/c/mtime was Re: Directory notification problem Gerhard Mack
2001-10-16 18:56 ` Riley Williams
2001-10-03 15:15 ` Alex Larsson
2001-10-03 21:26 ` Andi Kleen
2001-10-05 12:44 ` Padraig Brady [this message]
2001-10-05 12:59 ` Andrew Pimlott
2001-10-05 13:01 ` Andi Kleen
2001-10-05 13:15 ` Padraig Brady
2001-10-05 14:38 ` Andi Kleen
2001-10-05 15:00 ` Padraig Brady
2001-10-05 19:12 ` Andi Kleen
2001-10-08 8:39 ` Padraig Brady
2001-10-08 8:58 ` Padraig Brady
2001-10-08 10:04 ` Trond Myklebust
2001-10-05 20:22 ` Bernd Eckenfels
2001-10-03 17:45 ` Bernd Eckenfels
2001-10-13 15:24 ` Jamie Lokier
2001-10-13 16:12 ` Andi Kleen
2001-10-13 19:38 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BBDAB24.7000909@antefacto.com \
--to=padraig@antefacto.com \
--cc=ak@suse.de \
--cc=alexl@redhat.com \
--cc=drepper@cygnus.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.