Date: Wed, 17 Dec 2014 11:39:37 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: arch@freebsd.org Subject: Re: Change default VFS timestamp precision? Message-ID: <20141217105256.J1490@besplex.bde.org> In-Reply-To: <20141216233844.GA1490@stack.nl> References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Dec 2014, Jilles Tjoelker wrote: > Although some breakage may be caused, increasing precision sounds fine > to me, but only to the level of microseconds, since there is no way to > set a timestamp to the nanosecond (this would be futimens/utimensat). It > is easy to be surprised when cp -p creates an file that appears older > than the original. As I said in too many more words in another reply. > To avoid cross-arch surprises with applications that use > second-resolution APIs, either all or no architectures should generate > timestamps more accurate than seconds. That might be a feature for finding bugs. And it doesn't work for avoiding them, because foreign file systems may have uncontrollable timestamp precision. E.g., a foreign nfs server. > There is no benefit for the particular case of make(1), since it only > uses timestamps in seconds. Urk, I now rememeber seeing that 15-20 years ago and deciding that the problem with timestamps for make couldn't be very large. > A quick grep also shows various calls to utime(3) with a non-NULL timep > argument. The ones in contrib/bmake and usr.bin/make definitely look > incorrect. Do you mean that they are incorrect because they use utime(3) and not utimes(3), or just because they use the non-NULL timep? The latter is just a style bug in at least usr.bin/make. Since it hasn't caught up with the existence of utimes(3), it is reasonable for it to also have not caught up with the existence of the non-NULL timep. It just wants to set the time to the current time. It uses its own copy of the current time for this. Perhaps this is technically better too -- it makes "make -t" touch everything with the same time. This reminds me of related bugs in touch(1): - touch also tries first with a non-NULL timep. So it uses its own idea of the current time. This is normally the one returned a little in the past by gettimeofday(). It has microseconds resolution. This normally succeeds, giving a result that is inconsistent with the one that would result from using a NULL timep, since the kernel now honors vfs.timestamp_precision and that is not usually 2. - sometimes the first try fails. Then touch retries with a NULL timep, if the semantics allow this. Sometimes this succeeds. - sometimes both tries fail due to permissions problems. Then touch used to retry using read() and write(). Someone removed this, with the justification that all file systems support utimes(). But this is broken, since touching for read requires only read permission, while utimes() requires some sort of write permission. For touching for write, I don't see any problem now except for the above ordering problems: a NULL timep should be tried first since it requires fewer permissions and gives the best semantics; if it fails then there is no point in retrying with a non-NULL timep. The non-NULL timep in make gives the following bug since make doesn't retry with a NULL timep: make -t fails if the files ar writeable but not owned. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141217105256.J1490>