Date: Thu, 20 Aug 1998 09:30:21 +1000 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <98Aug20.093008est.40368@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
On Wed, 19 Aug 1998 13:40:32 +1000, Joel Ray Holveck <joelh@gnu.org> wrote: > Are there >any standards which define time_t as a 32-bit value? According to my references, ISO 9899:1990 (which is the same as ANSI C) section 7.12.1 states "... clock_t and time_t which are arithmetic types capable of representing times". There's no reference to the size or epoch of time_t. Section 7.12.2.4 (the time function) states "the time function returns the implementation's best approximation to the current calendar time" and "the encoding of the value is unspecified". I don't know if this is changed in C9X, or is POSIX is more specific (I suspect it might be). [64-bit machine implies 64-bit time_t and requires re-compile] > 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 :-(. > 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 On Wed, 19 Aug 1998 14:25:27 +1000, Terry Lambert <tlambert@primenet.com> wrote: >> 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 > >Har. And then I use backup/restore, and everything goes to hell. dump/restore obviously need to be updated for any change in the FS code. This should be fairly trivial - copying the disk structure (a FS epoch in the header, with relative times in the `inodes') would be the easiest to make backward compatible and the most efficient to dump (which is more time critical than restore in general). I agree that there would be a problem restoring the timestamps on files that are more than 68 years older than the filesystem - how real this problem would be, I don't know. What is the oldest file or backup that you curently have? What is the oldest backup that you can still read? >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? >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? An upper limit is the rate at which the updated inodes can be written (although soft updates increase this because you don't have to physically write the inode every time you change it). > 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 :-). 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. > Existing archive formats don't >have this relative offset stored. You can treat them as having a relative offset from a FS creation time of 1970/1/1. >> This approach does mean that a filesystem won't last more than 69 >> years, but that seems adequate. > >So did a two character date field, and a 2038 limit, when the issues >were first originated. 8-). Agreed, but IMHO: 1) Filesystems (in general) don't last longer than the hardware that they are written on. (Although RAID can change this). I am not aware of any hardware that is likely to allow you to maintain a filesystem for >68 years. 2) The current FS size limits (512GB - 1TB were calculated recently) are likely to become a serious issue, requiring re-thinking of the FS layout, before the date does. 3) The current FS cannot be grown without a newfs. What are the chances of a FS lasting more >68 years without running out of space? >> .. 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. > >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. On Thu, 20 Aug 1998 04:57:20 +1000, Garance A Drosihn <drosih@rpi.edu> wrote: > 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. Apart from the number of fractional bits, that's basically what I was suggesting. Note that converting between a struct timespec and fractional bits would require multiplication and division. If we're not too fussed about the accuracy of the disk timestamp, we could just store the bottom 50 bits of tv_sec and the top 14 active bits of tv_nsec (the top 2 bits of tv_nsec aren't used). This means the conversion between struct timespec and inode time is just shift and mask). >It just seems weird to say we need all 64 bits for time_t. Changing >time_t to be 48 or 56 bits This would cause the greatest amount of pain (unless you have a 48 or 56 bit int): time_t needs to be defined as an integral type. The disk inode times don't need to be stored as time_t (or struct timespec). There just needs to be a reasonably efficient way of converting between a struct timespec and disk time without losing a significant amount of time information. >(I just picked 1024'ths of a second because I have a vague recollection >of IBM using that for it's STCK (store clock) instruction, but my memory >might be playing tricks on me there...) If you're talking about the 360/370 architecture, the clock is stored as 64-bits, incremented at an effective rate of 4096MHz - ie the top word represents units of 2^20 usec, which isn't quite seconds. The counter wraps around in ~140 years, and originally used an epoch of 1900/1/1 (although I believe it might have changed). I don't believe this is a particularly helpful format :-). On Thu, 20 Aug 1998 05:30:13 +1000, Heikki Suonsivu <hsu@clinet.fi> wrote: >There are 1000000000 nanoseconds in a second. Thus the nanosecond value >has two high bits which are currently always zero, and could be used to >flag various things, like "this is a 62bit second value instead of 32bit >second+30bit nanosecond value." This strikes me as the worst of all possible worlds :-). We lose the sub-second precision in the future, when computers are becoming so fast that knowing the fractional part of the second is important (especially to make). You need both sets of code, and need conditional tests (which are slow and will get more expensive as computers get faster). 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. 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). 3) Redefine the epoch. The current time_t allows the representation of dates in the range (epoch +/- 68 years), with the exception of (epoch - 1 second). The problem with (epoch - 1 second) makes it difficult to pick an epoch in the future (unfortunately). This will break any code that `knows' the epoch (and may contravene POSIX). Given the requirement that the selected epoch be in the past, the epoch will probably need to be redefined every 50 years or so, with much pain each time. cpio/tar/restore etc will probably need some way for the operator to tell them what epoch the archive was made in. 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?98Aug20.093008est.40368>