Date: Wed, 19 Aug 1998 23:38:22 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: joelh@gnu.org Cc: hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <v04011705b2013551cf10@[128.113.24.147]> In-Reply-To: <199808192249.RAA14808@detlev.UUCP> References: <v04011704b200cd235416@[128.113.24.147]> (message from Garance A Drosihn on Wed, 19 Aug 1998 14:57:20 -0400) <v04011704b200cd235416@[128.113.24.147]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:49 PM -0500 8/19/98, Joel Ray Holveck wrote: > Garance wrote: >> 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!) Back in the 80's, I worked on a mainframe OS which also stored lastdatachangetime in seconds. It also had make. It also ran on multiprocessors, which can make things just a little more interesting. Occasionally we would see situations where a make would not "work as desired", because two files would have the same timestamp to within a second. FileA was really older than FileB, and FileB needed to be remade when FileA changed, but it wouldn't be remade because they both seemed to have the same timestamp. It didn't happen all that often, but when it did it would be really irritating to figure out why things weren't working. We updated that operating system to keep filechange timestamps to greater than a second resolution. My guess is that as personal computers get faster and faster, the same sort of thing can and will happen. Just think, before we see the year 2039, we'll be seeing multi-processor Mckinley-class machines selling for $800 from insight... :-) (reference to some dual-processor PPro machines I just bought...) Of course, there is one very significant difference with most personal computers. There is usually only one person making system-level changes on a given machine at a time. If I remember the problem on the mainframe correctly, it tended to come up because one systems-programmer person was installing changes to some system-include library at the same time another systems-programmer was recompiling pieces of the system... >> 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. Well, that would be nicer. I think IBM used 1024's of a second, and (whatever they did use) I always thought it was an odd choice... I should see if I can dig up an old 370/XA-architecture manual and get the right details. Actually, I think it'd be fine to split the extra 32 bits in half. Use 16 bits to extend the range of time_t, and sixteen bits to increase the resolution of timestamps in the filesystem. If time_t were 48 bits, when would we be running into *that* limit? --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute 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?v04011705b2013551cf10>