To: linux-kernel@vger.kernel.org
Cc: Jamie Lokier <jamie@shareable.org>, Paul Eggert <eggert@gnu.org>,
       Andi Kleen <ak@suse.de>, gcc@gcc.gnu.org, bug-coreutils@gnu.org
Subject: Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
From: "James H. Cloos Jr." <cloos@jhcloos.com>
In-Reply-To: <20040402011411.GE28520@mail.shareable.org> (Jamie Lokier's
 message of "Fri, 2 Apr 2004 02:14:11 +0100")
References: <200404011928.VAA23657@faui1d.informatik.uni-erlangen.de>
	<20040401220957.5f4f9ad2.ak@suse.de> <7w3c7nb4jb.fsf@sic.twinsun.com>
	<20040402011411.GE28520@mail.shareable.org>
Date: Fri, 02 Apr 2004 02:57:41 -0500
Message-ID: <m3isgi4xsa.fsf@lugabout.jhcloos.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1106
Lines: 20

>>>>> "Jamie" == Jamie Lokier <jamie@shareable.org> writes:

Jamie> When re-reading an inode, rounding the time up is done by
Jamie> setting the tv_nsec field to 999999999.

Jamie> If the on-disk timestamp is "now", i.e. the current second if
Jamie> it's a 1-second resolution, then we can avoid setting the
Jamie> timestamp to a future time by setting the tv_nsec field to the
Jamie> current wall time's nanosecond value.  There is no need to
Jamie> round the time up any more than that.

Given how much time it will take to compare the file's timestamp to
current before choosing 999999999 or now for the tv_nsec field, is
it a reasonable shortcut to just always use now's nsec value?

Obviously it is not *that* many cycles to do the compare, but we are
talking about a nanoseconds field, and the current tv_sec could
increment during the compare....

-JimC

-
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/