From: shejialuo <shejialuo@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
Patrick Steinhardt <ps@pks.im>
Subject: [PATCH v2 0/4] align the behavior when opening "packed-refs"
Date: Wed, 7 May 2025 22:52:15 +0800 [thread overview]
Message-ID: <aBtzn4nwLsI9p5Cp@ArchLinux> (raw)
In-Reply-To: <aBo7OiCKHTyT4DzH@ArchLinux>
Hi All:
As discussed in [1], we need to use mmap mechanism to open large
"packed_refs" file to save the memory usage. This patch mainly does the
following things:
1: Fix an issue that we would report an error when the "packed-refs"
file is empty, which does not align with the runtime behavior.
2-4: Extract some logic from the existing code and then use these
created helper functions to let fsck code to use mmap necessarily
[1] https://lore.kernel.org/git/20250503133158.GA4450@coredump.intra.peff.net
Really thank Peff and Patrick to suggest me to do above change.
---
Change since v1:
1. Update the commit message of [PATCH 1/4]. And use redirection to
create an empty file instead of using `touch`.
2. Don't use if for the refactored function in [PATCH 3/4] and then
update the commit message to align with the new function name.
3. Enhance the commit message of [PATCH 4/4].
Thanks,
Jialuo
shejialuo (4):
packed-backend: fsck should allow an empty "packed-refs" file
packed-backend: extract snapshot allocation in `load_contents`
packed-backend: extract munmap operation for `MMAP_TEMPORARY`
packed-backend: mmap large "packed-refs" file during fsck
refs/packed-backend.c | 113 ++++++++++++++++++++++++---------------
t/t0602-reffiles-fsck.sh | 13 +++++
2 files changed, 82 insertions(+), 44 deletions(-)
Range-diff against v1:
1: aa9037ebfa ! 1: 26c3fd55a8 packed-backend: skip checking consistency of empty packed-refs file
@@ Metadata
Author: shejialuo <shejialuo@gmail.com>
## Commit message ##
- packed-backend: skip checking consistency of empty packed-refs file
+ packed-backend: fsck should allow an empty "packed-refs" file
- In "load_contents", when the "packed-refs" is empty, we will just return
- the snapshot. However, we would report an error to the user when
- checking the consistency of the empty "packed-refs".
-
- We should align with the runtime behavior. As what "load_contents" does,
- let's check whether the file size is zero and if so, we will skip
- checking the consistency and simply return.
+ During fsck, an empty "packed-refs" gives an error; this is unwarranted.
+ We should just skip checking the content of "packed-refs" just like the
+ runtime code paths such as "create_snapshot" which simply returns the
+ "snapshot" without checking the content of "packed-refs".
Signed-off-by: shejialuo <shejialuo@gmail.com>
@@ t/t0602-reffiles-fsck.sh: test_expect_success SYMLINKS 'the filetype of packed-r
+ cd repo &&
+ test_commit default &&
+
-+ touch .git/packed-refs &&
++ >.git/packed-refs &&
+ git refs verify 2>err &&
+ test_must_be_empty err
+ )
2: 852e8a606b = 2: 4604be8b51 packed-backend: extract snapshot allocation in `load_contents`
3: de146155f6 ! 3: c0609afac9 packed-backend: extract munmap operation for `MMAP_TEMPORARY`
@@ Commit message
is "MMAP_TEMPORARY". We also need to do this operation when checking the
consistency of the "packed-refs" file.
- Create a new function "munmap_snapshot_if_temporary" to do above and
+ Create a new function "munmap_temporary_snapshot" to do above and
change "create_snapshot" to align with the behavior.
Suggested-by: Jeff King <peff@peff.net>
@@ refs/packed-backend.c: static int allocate_snapshot_buffer(struct snapshot *snap
return 1;
}
-+static void munmap_snapshot_if_temporary(struct snapshot *snapshot)
++static void munmap_temporary_snapshot(struct snapshot *snapshot)
+{
-+ if (mmap_strategy != MMAP_OK && snapshot->mmapped) {
-+ /*
-+ * We don't want to leave the file mmapped, so we are
-+ * forced to make a copy now:
-+ */
-+ size_t size = snapshot->eof - snapshot->start;
-+ char *buf_copy = xmalloc(size);
++ char *buf_copy;
++ size_t size;
+
-+ memcpy(buf_copy, snapshot->start, size);
-+ clear_snapshot_buffer(snapshot);
-+ snapshot->buf = snapshot->start = buf_copy;
-+ snapshot->eof = buf_copy + size;
-+ }
++ if (!snapshot)
++ return;
++
++ /*
++ * We don't want to leave the file mmapped, so we are
++ * forced to make a copy now:
++ */
++ size = snapshot->eof - snapshot->start;
++ buf_copy = xmalloc(size);
++
++ memcpy(buf_copy, snapshot->start, size);
++ clear_snapshot_buffer(snapshot);
++ snapshot->buf = snapshot->start = buf_copy;
++ snapshot->eof = buf_copy + size;
+}
+
/*
@@ refs/packed-backend.c: static struct snapshot *create_snapshot(struct packed_ref
- snapshot->buf = snapshot->start = buf_copy;
- snapshot->eof = buf_copy + size;
- }
-+ munmap_snapshot_if_temporary(snapshot);
++ if (mmap_strategy == MMAP_TEMPORARY && snapshot->mmapped)
++ munmap_temporary_snapshot(snapshot);
return snapshot;
}
4: be1e9e2540 ! 4: c868e3dd16 packed-backend: use mmap when opening large "packed-refs" file
@@ Metadata
Author: shejialuo <shejialuo@gmail.com>
## Commit message ##
- packed-backend: use mmap when opening large "packed-refs" file
+ packed-backend: mmap large "packed-refs" file during fsck
- We use "strbuf_read" to read the content of "packed-refs". However, this
- is a bad practice which would consume a lot of memory usage if there are
- multiple processes reading large "packed-refs".
+ During fsck, we use "strbuf_read" to read the content of "packed-refs"
+ without using mmap mechanism. This is a bad practice which would consume
+ more memory than using mmap mechanism. Besides, as all code paths in
+ "packed-backend.c" use this way, we should make "fsck" align with the
+ current codebase.
As we have introduced two helper functions "allocate_snapshot_buffer"
and "munmap_snapshot_if_temporary", we could simply call these functions
@@ refs/packed-backend.c: static int packed_fsck(struct ref_store *ref_store,
+ if (!allocate_snapshot_buffer(snapshot, fd, &st))
goto cleanup;
- }
-+ munmap_snapshot_if_temporary(snapshot);
- ret = packed_fsck_ref_content(o, ref_store, &sorted, packed_ref_content.buf,
- packed_ref_content.buf + packed_ref_content.len);
++ if (mmap_strategy == MMAP_TEMPORARY && snapshot->mmapped)
++ munmap_temporary_snapshot(snapshot);
++
+ ret = packed_fsck_ref_content(o, ref_store, &sorted, snapshot->start,
+ snapshot->eof);
if (!ret && sorted)
--
2.49.0
next prev parent reply other threads:[~2025-05-07 14:52 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 16:39 [PATCH 0/4] align the behavior when opening "packed-refs" shejialuo
2025-05-06 16:41 ` [PATCH 1/4] packed-backend: skip checking consistency of empty packed-refs file shejialuo
2025-05-06 18:42 ` Junio C Hamano
2025-05-07 12:09 ` shejialuo
2025-05-06 19:14 ` Junio C Hamano
2025-05-07 12:10 ` shejialuo
2025-05-06 16:41 ` [PATCH 2/4] packed-backend: extract snapshot allocation in `load_contents` shejialuo
2025-05-06 19:16 ` Junio C Hamano
2025-05-06 16:41 ` [PATCH 3/4] packed-backend: extract munmap operation for `MMAP_TEMPORARY` shejialuo
2025-05-06 18:52 ` Junio C Hamano
2025-05-06 22:17 ` Junio C Hamano
2025-05-07 12:21 ` shejialuo
2025-05-06 16:41 ` [PATCH 4/4] packed-backend: use mmap when opening large "packed-refs" file shejialuo
2025-05-06 19:00 ` Junio C Hamano
2025-05-06 22:18 ` Junio C Hamano
2025-05-07 12:34 ` shejialuo
2025-05-07 14:52 ` shejialuo [this message]
2025-05-07 14:53 ` [PATCH v2 1/4] packed-backend: fsck should allow an empty " shejialuo
2025-05-07 14:53 ` [PATCH v2 2/4] packed-backend: extract snapshot allocation in `load_contents` shejialuo
2025-05-07 14:53 ` [PATCH v2 3/4] packed-backend: extract munmap operation for `MMAP_TEMPORARY` shejialuo
2025-05-08 19:57 ` Jeff King
2025-05-08 20:05 ` Junio C Hamano
2025-05-09 15:03 ` shejialuo
2025-05-07 14:54 ` [PATCH v2 4/4] packed-backend: mmap large "packed-refs" file during fsck shejialuo
2025-05-08 20:07 ` Jeff King
2025-05-09 15:21 ` shejialuo
2025-05-09 15:59 ` Jeff King
2025-05-09 16:40 ` shejialuo
2025-05-07 22:51 ` [PATCH v2 0/4] align the behavior when opening "packed-refs" Junio C Hamano
2025-05-08 20:08 ` Jeff King
2025-05-08 20:20 ` Junio C Hamano
2025-05-08 20:33 ` Jeff King
2025-05-09 15:26 ` shejialuo
2025-05-11 13:59 ` [PATCH v3 0/3] " shejialuo
2025-05-11 14:01 ` [PATCH v3 1/3] packed-backend: fsck should allow an empty "packed-refs" file shejialuo
2025-05-12 8:36 ` Patrick Steinhardt
2025-05-12 12:25 ` shejialuo
2025-05-12 14:39 ` Patrick Steinhardt
2025-05-12 15:56 ` Jeff King
2025-05-12 17:18 ` Junio C Hamano
2025-05-13 5:08 ` Patrick Steinhardt
2025-05-13 7:06 ` shejialuo
2025-05-11 14:01 ` [PATCH v3 2/3] packed-backend: extract snapshot allocation in `load_contents` shejialuo
2025-05-12 8:37 ` Patrick Steinhardt
2025-05-12 10:35 ` shejialuo
2025-05-12 14:41 ` Patrick Steinhardt
2025-05-12 13:06 ` Jeff King
2025-05-13 6:55 ` shejialuo
2025-05-11 14:01 ` [PATCH v3 3/3] packed-backend: mmap large "packed-refs" file during fsck shejialuo
2025-05-12 13:08 ` Jeff King
2025-05-13 11:06 ` [PATCH v4 0/3] align the behavior when opening "packed-refs" shejialuo
2025-05-13 11:07 ` [PATCH v4 1/3] packed-backend: fsck should warn when "packed-refs" file is empty shejialuo
2025-05-13 16:30 ` Junio C Hamano
2025-05-14 12:51 ` shejialuo
2025-05-13 11:07 ` [PATCH v4 2/3] packed-backend: extract snapshot allocation in `load_contents` shejialuo
2025-05-13 11:07 ` [PATCH v4 3/3] packed-backend: mmap large "packed-refs" file during fsck shejialuo
2025-05-13 16:51 ` Junio C Hamano
2025-05-14 13:05 ` shejialuo
2025-05-14 15:48 ` [PATCH v5 0/3] align the behavior when opening "packed-refs" shejialuo
2025-05-14 15:50 ` [PATCH v5 1/3] packed-backend: fsck should warn when "packed-refs" file is empty shejialuo
2025-05-14 15:50 ` [PATCH v5 2/3] packed-backend: extract snapshot allocation in `load_contents` shejialuo
2025-05-14 15:50 ` [PATCH v5 3/3] packed-backend: mmap large "packed-refs" file during fsck shejialuo
2025-05-15 12:57 ` [PATCH v5 0/3] align the behavior when opening "packed-refs" Junio C Hamano
2025-05-21 16:31 ` Junio C Hamano
2025-05-22 5:50 ` Jeff King
2025-05-23 9:40 ` Patrick Steinhardt
2025-05-23 15:58 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBtzn4nwLsI9p5Cp@ArchLinux \
--to=shejialuo@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.