Date: Wed, 19 Aug 1998 05:02:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jbryant@unix.tfs.net Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG, jkh@time.cdrom.com Subject: Re: proposal to not change time_t Message-ID: <199808190502.WAA01835@usr06.primenet.com> In-Reply-To: <199808190209.VAA12243@unix.tfs.net> from "Jim Bryant" at Aug 18, 98 09:09:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? > > > > Ie: how do you plan to deal with disk files created after 2039? > > terry: simple. > > as i have been told in the past, i must remind you. if you can't > handle change, then don't run -current. This is really unacceptable. We have "nanosecond" resolution on timestamps (read the code to understand the quotes) for no good reason, and now we must modify inodes to go from 128 to 256 bytes for the bad reason of maintaining the nanosecond hack. > doing alternate similar time structures and having identical functions > with different names and arg sizeof is only a first, but necessary > step on the path to doing this. there are a lot of things tied to a > int32 time_t, so the preliminary work must be done, so as not to create > a bigger kludge than it should take. The FS is the big limiter. It was designed with this in mind (the spare fields are in the right byte order, and are zero'ed, prior to the nanosecond hack). You could argue that there are a lot of things tied to a lot of things, but this is no argument for stasis, nor is it an argument for unnecessary change above and beyond the necessary minimum. > this is a intermediate step so that filesystems can be developed, so > that standard utilities and programs can be migrated with as little > pain as possible. and so that developers and end-users can start > having time-issue-free user data immediately. This is a bad answer: "we're vulnerable, but we're working on it". >From what I can tell, very little new FS work (that has been committed to a BSD tree) has occurred since the initial integration of the Heidemann code was hurridly accomplished to beat a consent degree deadline. This is work on new FS's, though one has to admit that the infrastructure has suffered. Even old FS's, such as NULLFS, do not work. Some FS's are so obvious in their non-functionality that they are in fact diked out -- like LFS. So pardon me if I greet your optimism about an FS saviour just on the horizon with luke warm enthusiasm. > when a decision is made for real migration, #define's can be used as > an interim kludge to port EXISTING time_t code without code changes. The existing time_t is not a problem. The existing time_t is 32 bits. A 64 bit time_t is only a problem because the fields reserved for a 64 bit time_t were stolen. Recover them! They are stolen propery! They *belong* to time_t! > conversion utilities would be simple. The only person I have seen consistently pull monkeys from his butt lately is Loqui Chen. His contributions have been incisive, brilliant, and to the point, even if he occasionally makes mistakes (the one I saw was a mistake of omission that took Kirk McKusick to catch). My point in this observation is to answer "conversion utilities would be simple" with "yeah, and monkeys will fly out my butt". I have worked on in-place conversion tools, and I have been associated with projects that actually implemented them, and projects which contemplated implementing them. They are a royal bitch to get right. You not only have all of the normal state to deal with, but you have the conversion state to deal with as well; and unlike normal state, no one reserved space anywhere for the storage of conversion state. No thank you! > time_t cannot, as some i have seen suggesting, be changed ad-hoc. > with your experience, i would think you would recognize this in my > posting. Certainly *not* ad-hoc. But transparently to the extent that existing applications will continue to function, and the system and the associated utilities, and any new applications will not suffer the 2039 bug which existing applications will have to deal with until they are recompiled. > the freebsd user base may not be that big compared to others, but it > is still a user base. Which lived through omount, ostat, issetgid, unmapping page zero, the directory entry flags field split, a conversion to shared libraries, a conversion from native to BIOS-based boot blocks, and, perhaps most relevent to this discussion, a conversion from 32 bit to 64 bit off_t. Not to mention a VM system rewrite and the upcoming conversion to ELF... > if we don't set the standard now, linux will, or maybe netbsd... the > point is to set the standard by which all others are measured. NetBSD, not having screwed the pooch on a nanosecond hack, will merely eat the overhead of the 64 bit time_t in the inode, redo the quota structure, and convert the cylinder group and FS "last written" timestamp to monotimes. It will also eat a byte order overhead on architectures with a different byte order, where it screwed up and didn't reorder the spare and time_t fields in the inode to be 64 bit byte-order correct, with low 32 bits for the current time_t in the right place. Big deal. > it's important to solve the problem now, while so much attention is > being focused on the y2k thing, rather than merely waiting until 2037 > or 2038 to do anything about it. face it terry, not many of us will > still be around to cash in on that like the old-timers are on the y2k > issue that they caused. Speak for yourself. Many of the people I know fully expect to live a very, very, very long time, and thus live with the consequences of near-sighted decisions. On a strict linear projection (invalid, because the curve is historically exponential), human life expectancy will be going up one year per year in 2029. > honestly, i know you are proactive in some of your ideas, so let's > focus on what must be done to solve the problem before the rest of the > unix industry even thinks about it. face it, we do not have the > installed base of say linux, and i'll lay odds that if we move now, we > can beat them to the punch for that very reason. 1) Unbugger the nanosecond hack. 2) Redo (or temporarily disable) the quota code. 3) Change the cg and supperblock timestamps from time_t to monotime32_t. 4) Macro wrap all time_t accesses, taking into account byte order and existing sparing issues. 5) Define a manifest constant, because the CPP is too stupid to handle "#ifdef (sizeof(x) == 32)" because the preprocessor doesn't do what it's documentation says, and some lame-o put the sizeof() preprocessor directive into the compiler. 6) Rename time_t to xtime_t temporarily and compile the world with all warnings on. Everywhere it complains about time_t, put the reference macro. 7) Rename xtime_t to time_t. Repeat the process. 8) All time_t dependent system calls must change. Oh wait, that's just stat(2) and fstat(2), and they already have overlay space reserved for use by the declaration macros, once you do #1... 9) Fix third party futilities, as necessary. 10) Rejoice an be happy. > typedef long long int64; > typedef int64 time64_t; > time39_t time64(time64_t t); This is evil. Why not 64 bit everywhere? The only thing I can think of is to preserve a hack with ill-thought-out consequences. 8-(. > it's only a matter of time before ansi reconvenes a committee for c. Surprise. It's under review now. PS: so long as a 64 bit type is atomic, it meets ANSI's requirements. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199808190502.WAA01835>