From owner-freebsd-arch Fri Oct 26 19:18:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 6DD7E37B401 for ; Fri, 26 Oct 2001 19:18:54 -0700 (PDT) Received: from dialup-209.245.143.103.dial1.sanjose1.level3.net ([209.245.143.103] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xJ3V-0007VQ-00; Fri, 26 Oct 2001 19:18:38 -0700 Message-ID: <3BDA19B1.F26651DC@mindspring.com> Date: Fri, 26 Oct 2001 19:19:29 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Julian Elischer , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: <200110261707.f9QH7F437553@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > This is a bad idea. There's no point, because processors are only > getting faster. Even nanosecond resolution isn't enough and we have > other issues simply due to new computing methodologies such as parallel > and distributed processing. 'make's issues aren't enough to justify > complexifying atime/ctime/mtime. The "make" issues are real; they're just not solvable without some careful thought. The easiest fix would be to calculate the graph, and then act on it on the assumption that equal times are in order, and that a generation target for which an action was required was in fact generated, despite the timestamp being equal. The other suggestion I made earlier, ensuring monotonically increasing timestamps, works as well, but causes real problems at seconds of resolution, instead of smaller intervals of measure -- as Poul pointed out. A better way might be a file creation monotonicity stamp, on a per file, per directory basis, but that remains to be seen. We're all screwed without something like that, once quantum computing comes online, anyway. 8-). > The larger problem that we need to solve are the ridiculous calendar > limitations. We have to solve the problem *permanently* this time, > we have to solve them obviously, with as little additional complexity > as possible. We have to have a solution that is *uniform* across the > system, and a full 64 bit 1-second resolution field will do that. > We should not be screwing around with other clutter. I have this vision of an SF novel, where human civilization is destroyed 29 billion years from now because of 64 bit seconds, and the fact that all computer programming is done by machines instead of by humans... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message