Date: Wed, 19 Aug 1998 19:52:39 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: peter.jeremy@auss2.alcatel.com.au Cc: hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <199808200052.TAA15305@detlev.UUCP> In-Reply-To: <98Aug20.093008est.40368@border.alcanet.com.au> (message from Peter Jeremy on Thu, 20 Aug 1998 09:30:21 %2B1000) References: <98Aug20.093008est.40368@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808200052.TAA15305>