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

Re: [PATCH 01/02/RFC] implement a stat cache

From
Dmitry Potapov <dpotapov@gmail.com>
Date
Apr 21, 2008, 00:53 UTC
Message-ID
<20080421005340.GA2631@dpotapov.dyndns.org>
In-Reply-To
<alpine.LFD.1.10.0804201556290.2779@woody.linux-foundation.org>
On Sun, Apr 20, 2008 at 04:07:35PM -0700, Linus Torvalds wrote:
>
> Junio, what was the logic for that whole "has_symlink_leading_path()"
> thing? I forget. Whatever, it's broken.
===
commit f859c846e90b385c7ef873df22403529208ade50
Author: Junio C Hamano <junkio@cox.net>
Date:   Fri May 11 22:11:07 2007 -0700
    Add has_symlink_leading_path() function.
    When we are applying a patch that creates a blob at a path, or
    when we are switching from a branch that does not have a blob at
    the path to another branch that has one, we need to make sure
    that there is nothing at the path in the working tree, as such a
    file is a local modification made by the user that would be lost
    by the operation.
    Normally, lstat() on the path and making sure ENOENT is returned
    is good enough for that purpose.  However there is a twist.  We
    may be creating a regular file arch/x86_64/boot/Makefile, while
    removing an existing symbolic link at arch/x86_64/boot that
    points at existing ../i386/boot directory that has Makefile in
    it.  We always first check without touching filesystem and then
    perform the actual operation, so when we verify the new file,
    arch/x86_64/boot/Makefile, does not exist, we haven't removed
    the symbolic link arc/x86_64/boot symbolic link yet.  lstat() on
    the file sees through the symbolic link and reports the file is
    there, which is not what we want.
    The function has_symlink_leading_path() function takes a path,
    and sees if any of the leading directory component is a symbolic
    link.
    When files in a new directory are created, we tend to process
    them together because both index and tree are sorted.  The
    function takes advantage of this and allows the caller to cache
    and reuse which symbolic link on the filesystem caused the
    function to return true.
    The calling sequence would be:
        char last_symlink[PATH_MAX];
            *last_symlink = '\0';
            for each index entry {
                if (!lose)
                        continue;
                if (lstat(it))
                        if (errno == ENOENT)
                                ; /* happy */
                        else
                                error;
                else if (has_symlink_leading_path(it, last_symlink))
                        ; /* happy */
                else
                        error; /* would lose local changes */
                unlink_entry(it, last_symlink);
        }
===

And there are some cases where stat() on path is desirable: http://www.spinics.net/lists/git/msg63988.html

So while stat information for regular files is cached in the index, stat information for directories is not cached, and that appears to be wrong. Maybe, Lucano's cache makes sense if it stores only stat information for directories.

IIRC, some time ago, an otherwise reasonable patch for .gitignore was rejected just because it would drive the number calls to lstat() up as these calls on directories are not cached in the index.

Dmitry
Previous: Linus TorvaldsNext: Johan Herland
Message 17 of 39 in “Git performance on OS X”
  1. Pieter de BieApr 19, 2008
  2. Linus TorvaldsApr 19, 2008
  3. Linus TorvaldsApr 19, 2008
  4. Pieter de BieApr 19, 2008
  5. David KastrupApr 20, 2008
  6. Linus TorvaldsApr 19, 2008
  7. Pieter de BieApr 19, 2008
  8. Linus TorvaldsApr 19, 2008
  9. Junio C HamanoApr 20, 2008
  10. 01/02 implement a stat cacheLuciano Rocha, Apr 20, 2008
  11. 02/02 make use of the stat cacheLuciano Rocha, Apr 20, 2008
  12. Luciano RochaApr 20, 2008
  13. Linus TorvaldsApr 20, 2008
  14. Luciano RochaApr 20, 2008
  15. Linus TorvaldsApr 20, 2008
  16. Linus TorvaldsApr 20, 2008
  17. Dmitry PotapovApr 21, 2008
  18. Johan HerlandApr 21, 2008
  19. Junio C HamanoApr 21, 2008
  20. Linus TorvaldsApr 21, 2008
  21. Linus TorvaldsApr 21, 2008
  22. Junio C HamanoApr 21, 2008
  23. Linus TorvaldsApr 21, 2008
  24. Junio C HamanoApr 21, 2008
  25. David KastrupApr 21, 2008
  26. Jakub NarebskiApr 19, 2008
  27. Linus TorvaldsApr 19, 2008
  28. Linus TorvaldsApr 19, 2008
  29. Pieter de BieApr 19, 2008
  30. Linus TorvaldsApr 19, 2008
  31. Roman ShaposhnikApr 19, 2008
  32. Pieter de BieApr 19, 2008
  33. Linus TorvaldsApr 20, 2008
  34. Roman ShaposhnikApr 20, 2008
  35. Pieter de BieApr 19, 2008
  36. Linus TorvaldsApr 20, 2008
  37. Dmitry PotapovApr 20, 2008
  38. David KastrupApr 20, 2008
  39. Linus TorvaldsApr 19, 2008

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.