git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes

From
Lars Schneider <larsxschneider@gmail.com>
Date
Sep 8, 2016, 05:57 UTC
Message-ID
<F33245FC-C53A-4977-8E72-68AF3D2BB8BB@gmail.com>
In-Reply-To
<xmqqtwdrmuvo.fsf@gitster.mtv.corp.google.com>
Show 24 quoted lines
> On 07 Sep 2016, at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Eric Wong <e@80x24.org> 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

Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 15 in “Use CLOEXEC to avoid fd leaks”
  1. 0/2 Use CLOEXEC to avoid fd leakslarsxschneider@gmail.com, Sep 5, 2016
  2. 1/2 sha1_file: open window into packfiles with CLOEXEClarsxschneider@gmail.com, Sep 5, 2016
  3. Eric WongSep 5, 2016
  4. Jakub NarębskiSep 6, 2016
  5. Johannes SchindelinSep 6, 2016
  6. Lars SchneiderSep 7, 2016
  7. Eric WongSep 7, 2016
  8. 2/2 read-cache: make sure file handles are not inherited by child processeslarsxschneider@gmail.com, Sep 5, 2016
  9. Johannes SchindelinSep 6, 2016
  10. Eric WongSep 6, 2016
  11. Lars SchneiderSep 7, 2016
  12. Eric WongSep 7, 2016
  13. Junio C HamanoSep 7, 2016
  14. Lars SchneiderSep 8, 2016
  15. Junio C HamanoSep 8, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.