Date: Fri, 26 Oct 2001 09:18:07 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Julian Elischer <julian@elischer.org> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <24137.1004080687@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 26 Oct 2001 01:21:44 PDT." <Pine.BSF.4.21.0110260109050.8805-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0110260109050.8805-100000@InterJet.elischer.org>, Jul ian Elischer writes: >ufs has enough room to fix this.. >there has been a field defined in the on disk inode for nanosecs >in each of the time values... >if we take the lowest 8 bits of that field and re-assign it to be >the highest 8 bits of the seconds, then we have time accuracy down to >microseconds still and we expand file times by a factor >of 256 (which is all of recorded history plus some) > >we just always set those bits to 0 for the next 37 years and we don;t >really lose time resolution and we gain compatibility with the future.. >nothing these days has nonosecond resolution there anyhow.... "640K is enough for anybody" "There is no harm in tobacco" "Of course I'll respect you in the morning" etc etc 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. -- 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?24137.1004080687>