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 v5 0/3] align the behavior when opening "packed-refs"
Date: Wed, 14 May 2025 23:48:11 +0800 [thread overview]
Message-ID: <aCS7O8tNekg_u9Wp@ArchLinux> (raw)
In-Reply-To: <aCMnrwkoJ2WyqGZT@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 in v2:
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].
---
Change in v3:
1. Drop the patch which creates a new function
"munmap_temporary_snapshot". As discussed, there is no need to munmap
the file during fsck.
2. Allocate snapshot variable in the stack instead of heap.
3. Fix rebase issue, remove unneeded code to check the file size
explicitly.
---
Change in v4:
1. Report the "emptyPackedRefsFile(INFO)" to the user when the
"packed-refs" is empty instead of ONLY skipping checking the content and
update the shell script and commit message.
2. Apply Peff's advice to make [PATCH v3 2/3] more clear.
---
Change in v5:
1. Improve the commit message in the first patch to be more clear:
1. Talk about the current behavior, what error we would report if
"packed-refs" is empty.
2. To align with the runtime behavior, we should skip checking the
content of "packed-refs".
3. Why do we need to report to the user when the "packed-refs" is
empty
2. Fix grammar issue in the last patch.
Thanks,
Jialuo
shejialuo (3):
packed-backend: fsck should warn when "packed-refs" file is empty
packed-backend: extract snapshot allocation in `load_contents`
packed-backend: mmap large "packed-refs" file during fsck
Documentation/fsck-msgids.adoc | 6 +++
fsck.h | 1 +
refs/packed-backend.c | 73 ++++++++++++++++++++--------------
t/t0602-reffiles-fsck.sh | 17 ++++++++
4 files changed, 67 insertions(+), 30 deletions(-)
Range-diff against v4:
1: 75636c9c85 ! 1: 3487692a03 packed-backend: fsck should warn when "packed-refs" file is empty
@@ Metadata
## Commit message ##
packed-backend: fsck should warn when "packed-refs" file is empty
- During fsck, an empty "packed-refs" gives an error; this is unwarranted.
- The runtime code paths would accept an empty "packed-refs" file, such as
- "create_snapshot" would simply return the "snapshot" without checking
- the content of "packed-refs".
+ We assume the "packed-refs" won't be empty and instead has at least one
+ line in it (even when there are no refs packed, there is the file header
+ line). Because there is no terminating LF in the empty file, we will
+ report "packedRefEntryNotTerminated(ERROR)" to the user.
- And we should also skip checking the content of "packed-refs" when it is
- empty during fsck. However, we should think about whether we need to
- report something to the users in this case.
+ However, the runtime code paths would accept an empty "packed-refs"
+ file, for example, "create_snapshot" would simply return the "snapshot"
+ without checking the content of "packed-refs". So, we should skip
+ checking the content of "packed-refs" when it is empty during fsck.
After 694b7a1999 (repack_without_ref(): write peeled refs in the
rewritten file, 2013-04-22), we would always write a header into the
- "packed-refs" file where we would never create empty file since then.
- Because we only create empty "packed-refs" in the very early versions,
- we may tighten this rule in the future. In order to notify the users
- about this, we should at least report an warning to the users.
+ "packed-refs" file. So, versions of Git that are not too ancient never
+ write such an empty "packed-refs" file.
- But we need to consider the fsck message type carefully, it is not
- appropriate that we use "FSCK_ERROR". This is because we would
- definitely break the compatibility. Let's create a "FSCK_INFO" message
- id EMPTY_PACKED_REFS_FILE" to indicate that "packed-refs" is empty.
+ As an empty file often indicates a sign of a filesystem-level issue, the
+ way we want to resolve this inconsistency is not make everybody totally
+ silent but notice and report the anomaly.
+
+ Let's create a "FSCK_INFO" message id "EMPTY_PACKED_REFS_FILE" to report
+ to the users that "packed-refs" is empty.
Signed-off-by: shejialuo <shejialuo@gmail.com>
2: 1a5893379d = 2: 0d050849bc packed-backend: extract snapshot allocation in `load_contents`
3: 31e272db7e ! 3: fe5ffec8fb packed-backend: mmap large "packed-refs" file during fsck
@@ Commit message
current codebase.
As we have introduced the helper function "allocate_snapshot_buffer", we
- could simple use this function to use mmap mechanism.
+ can simply use this function to use mmap mechanism.
Suggested-by: Jeff King <peff@peff.net>
Suggested-by: Patrick Steinhardt <ps@pks.im>
--
2.49.0
next prev parent reply other threads:[~2025-05-14 15:47 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 ` [PATCH v2 0/4] align the behavior when opening "packed-refs" shejialuo
2025-05-07 14:53 ` [PATCH v2 1/4] packed-backend: fsck should allow an empty "packed-refs" file 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 ` shejialuo [this message]
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=aCS7O8tNekg_u9Wp@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).