From owner-freebsd-arch Fri Oct 26 10: 7:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C1DA437B403 for ; Fri, 26 Oct 2001 10:07:50 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QH7F437553; Fri, 26 Oct 2001 10:07:15 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 10:07:15 -0700 (PDT) From: Matthew Dillon Message-Id: <200110261707.f9QH7F437553@apollo.backplane.com> To: Julian Elischer Cc: Terry Lambert , Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. References: 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 For UFS we obviously re-coopt the nanosecond field. Thanks Kirk! I suggest simply changing di_atimensec (and friends) to di_atimemsb, to hold the msb 32 bits, allowing us to maintain backwards compatibility. The question before us is whether we should eat some of those 64 bits and attempt to store sub-second timestamps. 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 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 am not against adding additional fields to struct stat to support sub-second resolution for mtime, but I am against attempting to integrate such fields into st_atime/st_mtime/st_ctime directly. Unfortunately we only have two spare 64 bit fields in struct nstat. They aren't enough to fix the time fields and maintain backwards compatibility. Unless I'm missing something here, we are going to have to roll new syscalls for *stat() and *utimes() (any others?) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message