Date: Fri, 26 Oct 2001 11:00:53 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: tlambert2@mindspring.com, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <Pine.BSF.4.21.0110261051020.10928-100000@InterJet.elischer.org> In-Reply-To: <2912.1004113233@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I thonk you are wrong.. here's the way I see it.. Kirk is working on UFS2. All new systemsafter about the next 5 or 6 years will be created with UFS2. Therefore what we are looking for is a way that exisiting embedded systems can continue to run safely past 2038. (actually file access times ON DISK should be treated as unsigned as there were no UFS systems before 1970 but I digress) There are not going to be UP systems in the next 6 years tha can touch 2 DIFFERNT files withinn the same microsecond, and even if a MP system did so, there is no reason to not give them the same Microsecond timestamp, since they could have been to the same nanosecond too. At least we know that they do not have interdependencies or the system wouldn;t have scheduled them to differnt processors where the relative completion times couldn't be controlled. so it doesn't matter that we only have uSec resolution in that field.. but here;s a better idea anyhow.. take the TOP 2 bits.. they can never be used now anyhow.... that gives us nanosecond resolution, which is all we can report now anyway, and multiplies the seconds range by 4. Assuming that we do not allow access times < 1970 on disk (there were no such files then, then we are ok up to the year 2600, by which time we hope there are no embededded systems from the next 5 years still running..... On Fri, 26 Oct 2001, Poul-Henning Kamp wrote: > In message <3BD98B6A.DED6D38F@mindspring.com>, Terry Lambert writes: > >Poul-Henning Kamp wrote: > >> Your proposal would leave us with quarter-microsecond resolution, > >> and I'm pretty sure I can beat that to pulp in the next 10 years > >> on a RAM disk... > >> > >> There is no harm in having to run a rev on the UFS/FFS on-disk format, > >> when you hav 37 years to complete it. > > > >Or 10 years, if we go Julian's way. > > Julians way doesn't work: it has insufficient sub-second resolution. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0110261051020.10928-100000>