Date: Wed, 19 Aug 1998 10:54:27 +1000 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <98Aug19.105412est.40322@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
On Tue, 18 Aug 1998 14:52:17 -0500 (CDT), Jim Bryant <jbryant@unix.tfs.net> wrote: >what i would like to propose here is to create alternate, look-alike >functions. Note that time() is not a system call, it's a library function calling gettimeofday(2). And struct timeval (which gettimeofday() uses) uses longs rather than time_t. (I don't have a -current handy, so I'm not quite sure how the transition from struct timeval to struct timespec is handled). Overall, I don't believe that creating a new interface using a new q_time_t is warranted. BSD managed to change off_t from 32-bits to 64-bits without breaking everything. It should be possible to similarly change time_t. On Tue, 18 Aug 1998 20:40:15 +0000 (GMT), Terry Lambert <tlambert@primenet.com> wrote: >How do you propose to deal with the fact that the file timestamp >for FFS is a 32 bit value, and the spare fields that were intended >to be used to resolve the 2039 bug have been stolen to store >nanoseconds? One solution would be to add a creation time to the superblock (I think struct fs has still got free space) and then just store offsets from that creation time in the disk inodes (which are the critical structure, size-wise). The times in struct stat would be the sum of the fs_creat time and the relevant times in the disk inode. Whether struct inode contains a 32-bit or 64-bit seconds counter would depend on the relative efficiency/convenience of inode <-> dinode mapping vs inode time updating (and stat()ing). If the unused parts of the superblock are zero-filled, existing filesystems won't need updating immediately to be compatible with the changed definition. Storing the creation time as seconds only would mean that you don't need to add/subtract the tv_nsec fields (which is particularly messy because it wraps at an inconvenient 0x3b9aca00). This approach does mean that a filesystem won't last more than 69 years, but that seems adequate. A timestamp update tool would be trivial to write, but will need exclusive access to a partition for the time to read/write all the inodes (about the same as an fsck takes now). For a somewhat higher cost (and with kernel assistance), it should be possible to build a tool that can update the `fs_creat' and all associated inode timestamps for an active filesystem. 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). Peter == Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98Aug19.105412est.40322>