> On 07 Sep 2016, at 20:23, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Eric Wong <e@xxxxxxxxx> writes: > >> We probably should be using O_NOATIME for all O_RDONLY cases >> to get the last bit of performance out (especially since >> non-modern-Linux systems probably still lack relatime). > > No, please do not go there. > > The user can read from a file in a working tree using "less", > "grep", etc., and they all update the atime, so should "git grep". > We do not use atime ourselves on these files but we should let > outside tools rely on the validity of atime (e.g. "what are the > files that were looked at yesterday?"). > > If you grep for noatime in our current codebase, you'd notice that > we use it only for files in objects/ hierarchy, and that makes very > good sense. These files are what we create for our _sole_ use and > no other tools can peek at them and expect to get any useful > information out of them (we hear from time to time that virus > scanners leaving open file descriptors on them causing trouble, but > that is an example of a useless access), and that makes a file in > objects/ hierarchy a fair game for noatime optimization. How do we deal with read-cache:ce_compare_data, though? By your definition above we shouldn't use NOATIME since the read file is not in objects/. However, the file read is not something the user explicitly triggers. The read is part of the Git internal "clean" machinery. What would you suggest? Should I open the file with or without NOATIME? Thanks, Lars