From owner-freebsd-hackers Wed Aug 19 17:53:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12691 for freebsd-hackers-outgoing; Wed, 19 Aug 1998 17:53:40 -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 RAA12628 for ; Wed, 19 Aug 1998 17:53:29 -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 TAA17481; Wed, 19 Aug 1998 19:54:18 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id TAA15305; Wed, 19 Aug 1998 19:52:39 -0500 (CDT) (envelope-from joelh) Date: Wed, 19 Aug 1998 19:52:39 -0500 (CDT) Message-Id: <199808200052.TAA15305@detlev.UUCP> To: peter.jeremy@auss2.alcatel.com.au CC: hackers@FreeBSD.ORG In-reply-to: <98Aug20.093008est.40368@border.alcanet.com.au> (message from Peter Jeremy on Thu, 20 Aug 1998 09:30:21 +1000) Subject: Re: proposal to not change time_t From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <98Aug20.093008est.40368@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I expect that it would be a very natural transition, and won't >> break machines which dump time_t's into int's (lots of them, I >> expect), etc, etc. > I hope no-one uses int to store times. The return value from time() > was a long before time_t was added. Anyone who uses int deserves > to have a VAX 11/750 (or 11/780) dropped on them from a great height. :-) >> My biggest concerns are the filesystem, and network protocols which >> define a 32-bit time value. > One of the issues will be to locate and root out all these places. > It will be a particularly messy task :-(. Yes, this is true. >> What was the idea with using the reserved >> bits for ns precision anyway? Can we dike it back out? > I can see the need for mode Mode, perhaps. But I'm talking about the timestamp. >> Efficiency is not an issue, as of 2038, so long as there are tar files >> sufficient far in the past existant. > And functioning hardware that can read them. When's the last time you > saw a 7-track tape drive, an 8"-floppy or a punched-card reader? Do > you believe you'll be able to read today's Exabyte (or whatever) tape > in another 30 years? No, but I'll still probably be getting a digging in old mailing list archives and finding uuencoded tar's. (And in answer to your questions: I last used such a tape drive in '94 for real work, believe it or not. Didn't use a card reader that year, but did use a card punch (as a prank on a prof), as well as a paper tape punch and reader on an old military TTY I was converting for modern ham radio usage. 8" floppy earlier this year, while working on an old Tandy Xenix box at my old high school that is still in service.) >> The amount of relative time_t math based on the superblock values more >> than makes up for the storage requirements. > I don't know about this. How frequently are inode timestamps > updated? Every file access, unless you're using noatime. (Don't start throwing async stats at me, I don't feel like doing the math.) >> Consider a full system restore onto a newly created FS. > If this is the normal case for you, Terry, you need to invest in some > more reliable hardware :-). Or quit doing filesystem hacking, or running -current, or... > In general, full FS restores should be rare. In any case, for any > realistically configured system, the CPU should be spending most of > its time waiting for reads or writes to complete. On a realistically configured system, the users are generally waitingp for more disk space to become availible. :-) >>> should be possible to build a tool that can update the `fs_creat' and >>> all associated inode timestamps for an active filesystem. >> How can you tell the difference between an updated and a non-updated >> value if you carsh during update? > My idea was that the epoch conversion would occur sequentially by inode > number. The superblock would contain both the old epoch, the new epoch > and the inode number where the transition occurs. If the epoch is > always updated by a fixed amount, you could avoid storing both epochs. > If a crash occurs then inodes around the transition maker may be > inaccurate. The number of potentially inaccurate inodes can be > controlled by adjusting the rate at which the updated superblock is > re-written. If the difference is sufficiently large, it should be > possible for the operator to work out which epoch is appropriate > during the fsck. It would be also possible to generate the new data in a separate location, write a flag saying it's valid, ya da ya da ya da... > In general, there are a number of possible solutions to the 2038 problem, > all of which have different problems: > 1) Redefine time_t as a 64-bit signed value. This will require > special handling in the UFS disk inode. It will also break a > substantial amount of old code which explicitly uses long as well as > format strings that print/scan times. The painful day when it all > needs to be done again is postponed until sometime after the > expected death of the Universe. I still maintain that parts of the headache can be kept at a minimum by waiting until longs become 64-bit by the natural progression of hardware. > 2) Redefine time_t as a 32-bit unsigned value. This postpones the > wrap- around to sometime in 2006. Since time_t doesn't change in > size, much less code will break - the breakage will be limited to > code that tries to represent times prior to 1970/1/1 (such code > already has the problem that 1969/12/31 23:59:59 UTC is not > representable according to the C standard). (There may also be > problems for code that calculates differences between times, on > machines that don't ignore integer overflow, or don't use 2's > complement arithmetic). This also means violating the C standard anyway, no? > 3) Redefine the epoch. I'm not even going to waste my time with that one. Best, 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