From owner-freebsd-hackers Wed Aug 19 15:51:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21383 for freebsd-hackers-outgoing; Wed, 19 Aug 1998 15:51:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com ([208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21357 for ; Wed, 19 Aug 1998 15:50:50 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-120.camalott.com [208.229.74.120]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id RAA08269; Wed, 19 Aug 1998 17:51:21 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id RAA14808; Wed, 19 Aug 1998 17:49:42 -0500 (CDT) (envelope-from joelh) Date: Wed, 19 Aug 1998 17:49:42 -0500 (CDT) Message-Id: <199808192249.RAA14808@detlev.UUCP> To: drosih@rpi.edu CC: peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG In-reply-to: (message from Garance A Drosihn on Wed, 19 Aug 1998 14:57:20 -0400) Subject: Re: proposal to not change time_t From: Joel Ray Holveck Reply-to: joelh@gnu.org References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Alternatively, do we really need nsec timestamps in inodes? We could >> store a 64-bit seconds timestamp in the inode and have SYS_stat() map >> it to a struct timespec with a zero tv_nsec. (Less convenient options >> which address the make's difficulties in chronologically ordering >> rapidly created files would be to use a 64-bit fixed-point number >> with 8, 16 or even 24 fractional bits). > I do think it's useful to have time resolution be better than 1 > second. I still haven't heard why this is a useful filesystem addition. (Please no flame wars!) > At the same time, I would like to put off newfs'ing systems for a new > format as long as possible, while still solving the 2039 issue. And while we're at it, I'd like a pony. > We currently have the 32-bit time_t, and the 32 bits stolen to give > us nanosecond timestamps. Just how weird would it be to make it a > 64-bit time field which was 1024'ths of a second? To get a valid > time_t (in seconds) you'd have to shift the value a few bits, and > you could provide that value in a 64-bit number if you want. Ugh. At least make it a multiple of 8 bits, ie 255ths of a second. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message