Date: Fri, 26 Oct 2001 09:47:34 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Julian Elischer <julian@elischer.org>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <3BD993A6.E6B12512@mindspring.com> References: <2912.1004113233@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > >> 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. According to you, that won't bite anyone for 10 years. Also: no one has ever justified this for anything other than "make", which looks only at mtime, so having such high resolution for atime and ctime is really not necessary, unless it can be justified. I have yet to see a demonstration of another system failing and FreeBSD succeeding as a result of the time resolution on file timestamps. The "mtime" argument is really only valid in the case that you rerun a build in a subsecond time with generated source code, such that the generate code ends up with the same mtime timestamp as the previously generated object code. I fully admit that subsecond resolution on mtime is necessary to avoid stale files in the case that you can regenerate them with different contents in under a second since the previous build. Frankly, I'd be much more concerned that the local time is not sent with all NFSv4 requests, so that the local delta can be calculated, rather than relying on unreliable ntpd drift synchronization, which is certainly in the second range in unreliability. -- Terry 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?3BD993A6.E6B12512>