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

Re: [PATCH] sha1_file: introduce close_one_pack() to close packs on fd pressure

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jul 30, 2013, 07:51 UTC
Message-ID
<CAPig+cR68PQ62JC266iGBidD-udBq2BaL-BWaTpY1JkWWBOp0Q@mail.gmail.com>
In-Reply-To
<1375157113-608-1-git-send-email-bcasey@nvidia.com>
On Tue, Jul 30, 2013 at 12:05 AM, Brandon Casey <bcasey@nvidia.com> wrote:
Show 17 quoted lines
> When the number of open packs exceeds pack_max_fds, unuse_one_window()
> is called repeatedly to attempt to release the least-recently-used
> pack windows, which, as a side-effect, will also close a pack file
> after closing its last open window.  If a pack file has been opened,
> but no windows have been allocated into it, it will never be selected
> by unuse_one_window() and hence its file descriptor will not be
> closed.  When this happens, git may exceed the number of file
> descriptors permitted by the system.
>
> This latter situation can occur in show-ref or receive-pack during ref
> advertisement.  During ref advertisement, receive-pack will iterate
> over every ref in the repository and advertise it to the client after
> ensuring that the ref exists in the local repository.  If the ref is
> located inside a pack, then the pack is opened to ensure that it
> exists, but since the object is not actually read from the pack, no
> mmap windows are allocated.  When the number of open packs exceeds
> pack_max_fds, unuse_one_window() will not able to find any windows to

s/not able/not be able/ ...or... s/not able to find/not find/

Show 26 quoted lines
> free and will not be able to close any packs.  Once the per-process
> file descriptor limit is exceeded, receive-pack will produce a warning,
> not an error, for each pack it cannot open, and will then most likely
> fail with an error to spawn rev-list or index-pack like:
>
>    error: cannot create standard input pipe for rev-list: Too many open files
>    error: Could not run 'git rev-list'
>
> This is not likely to occur during upload-pack since upload-pack
> reads each object from the pack so that it can peel tags and
> advertise the exposed object.  So during upload-pack, mmap windows
> will be allocated for each pack that is opened and unuse_one_window()
> will eventually be able to close unused packs after freeing all of
> their windows.
>
> When we have file descriptor pressure, in contrast to memory pressure,
> we need to free all windows and close the pack file descriptor so that
> a new pack can be opened.  Let's introduce a new function
> close_one_pack() designed specifically for this purpose to search
> for and close the least-recently-used pack, where LRU is defined as
>
>    * pack with oldest mtime and no allocated mmap windows or
>    * pack with the least-recently-used windows, i.e. the pack
>      with the oldest most-recently-used window
>
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
Previous: Brandon CaseyNext: Junio C Hamano
Message 2 of 23 in “sha1_file: introduce close_one_pack() to close packs on fd pressure”
  1. sha1_file: introduce close_one_pack() to close packs on fd pressureBrandon Casey, Jul 30, 2013
  2. Eric SunshineJul 30, 2013
  3. Junio C HamanoJul 30, 2013
  4. Jeff KingJul 30, 2013
  5. Brandon CaseyJul 30, 2013
  6. 1/2 sha1_file: introduce close_one_pack() to close packs on fd pressureBrandon Casey, Jul 31, 2013
  7. 2/2 Don't close pack fd when free'ing pack windowsBrandon Casey, Jul 31, 2013
  8. Antoine PelisseJul 31, 2013
  9. Fredrik GustafssonJul 31, 2013
  10. Brandon CaseyJul 31, 2013
  11. Fredrik GustafssonJul 31, 2013
  12. Brandon CaseyJul 31, 2013
  13. Thomas RastJul 31, 2013
  14. Junio C HamanoAug 1, 2013
  15. Brandon CaseyAug 1, 2013
  16. Junio C HamanoAug 1, 2013
  17. Brandon CaseyAug 1, 2013
  18. Brandon CaseyAug 1, 2013
  19. Junio C HamanoAug 1, 2013
  20. Brandon CaseyAug 1, 2013
  21. sha1_file: introduce close_one_pack() to close packs on fd pressureBrandon Casey, Aug 2, 2013
  22. Junio C HamanoAug 2, 2013
  23. Brandon CaseyAug 2, 2013

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.