Re: [PATCH] tmp-objdir: merge loose object index when migrating tmpdir

From: Justin Tobler <jltobler@gmail.com>
Date: Oct 23, 2026, 21:25 UTC
Message-ID: <atufODWNPJMbvMZu@denethor>
In-Reply-To: <attQtZ1dVoAnQznP@pks.im>

On 26/10/23 02:19PM, Patrick Steinhardt wrote:

Show 7 quoted lines

> On Thu, Oct 22, 2026 at 06:40:07PM -0500, Justin Tobler wrote:
> > When a repository is configured with a compatibility hash, each loose
> > object write also records a mapping between the object and its
> > compatibility hash in a "loose-object-idx" file. This index is located
> > in the same object database the object is written to. If batch fsync of
> 
> You probably mean "object directory", not "database"?

Ya, "object directory" would be more correct here. Will fix.

Show 10 quoted lines

> > loose objects is also enabled, the loose objects and index file are
> > instead written to a temporary object directory and expected to be
> > migrated to the primary object directory when the batch transaction
> > commits.
> > 
> > While migrating the loose objects works, the "loose-object-idx" file is
> > unable to be migrated if an index already exists in the primary object
> 
> The naming really throws me off, "index" to me is our staging area. What
> this is is a map. But oh, well, cannot change that now.

Agreed. I may change the commit message to call it a "mapping file" if that helps in any way.

[snip]

Show 8 quoted lines

> > Some other approaches I considered:
> >   - Storing the uncommitted object mapping entries in the transaction
> >     without writing a file and only writing on transaction commit. I
> >     chose to keep writing the temp index into the transaction so that
> >     child processes that write to the tempdir could still append entries.
> 
> Is that a theoretical scenario or do we actually have cases where a
> child process wants to write data into the quarantine directory, too?

I think a git-receive-pack(1) can spawn a git-unpack-objects(1) child process and write loose objects into the quarantine directory. Consequently, if a repository is configured with a compatibility hash, these loose objects would also end up writing mapping entries into the quarantine.

Show 8 quoted lines

> >   - Also writing mapping entires to the main ODB loose object index.
> >     This also didn't seem like a good apprach because it write entires
> >     that may not ultimately get committed.
> 
> Agreed, we shouldn't commit this before the actual objects exist. I bet
> we don't properly handle this during housekeeping either -- or at least
> I never stumbled over logic that prunes mappings when pruning the
> corresponding objects. But that's a problem to solve another day.

Yep, there doesn't appear to be any existing logic to prune entries from this mapping file. It can only grow in size. This seemed like a separate problem altogether though, so I didn't bother tackling that here.

Show 30 quoted lines

> > diff --git a/loose.c b/loose.c
> > index d6a2bb5ba3..79d4c256e0 100644
> > --- a/loose.c
> > +++ b/loose.c
> > @@ -265,3 +265,75 @@ void loose_object_map_clear(struct loose_object_map **map)
> >  	free(m);
> >  	*map = NULL;
> >  }
> > +
> > +int loose_object_idx_merge(struct repository *repo, const char *src,
> > +			   const char *dst)
> > +{
> > +	struct lock_file lock = LOCK_INIT;
> > +	struct strbuf buf = STRBUF_INIT;
> > +	struct stat st;
> > +	FILE *fp;
> > +	int fd = -1;
> > +	int ret;
> > +
> > +	fp = fopen(src, "r");
> > +	if (!fp) {
> > +		ret = error_errno(_("unable to open %s"), src);
> > +		goto out;
> > +	}
> > +	if (strbuf_getwholeline(&buf, fp, '\n') || strcmp(buf.buf, loose_object_header)) {
> > +		ret = error(_("invalid loose object index %s"), src);
> > +		goto out;
> > +	}
> 
> Curious. Why do we even expect that this file may be broken?

For our intended use case of reading the "loose-object-idx" file from the quarantine directory and merging its entries to the mapping file in the primary object directory, I wouldn't expect it to ever be broken. That is because realistically only a "loose-object-idx" that we create during the transaction should be written into the quarantine directory.

I chose to be more defensive here because the `loose_object_idx_merge()` function itself isn't aware of the circumstances regarding its use case. In theory, another caller could use any mapping file as the source. Ultimately though I don't feel too strongly either way and am happy to remove it if we don't like it.

Show 8 quoted lines

> > +	if (repo_hold_lock_file_for_update_timeout(repo, &lock, dst, 0, -1) < 0) {
> > +		ret = error_errno(_("unable to lock %s"), dst);
> > +		goto out;
> > +	}
> 
> With a timeout of -1 we'll block indefinitely. That doesn't feel like
> the best option to me, as the lockfile may be left over from a previous
> process. And Git locking up indefinitely feels suboptimal to me.

That's fair. I picked this value purely because I was closely following how `write_one_object()` implements its logic to update the "loose-object-idx" file.

Would it make sense to make this value configurable? Or would it be fine to just set it to 1000ms? If we change this here, maybe we should also change it for `write_one_object()` to match?

Show 8 quoted lines

> > +	fd = open(dst, O_WRONLY | O_CREAT | O_APPEND, 0666);
> 
> I don't think it's a good idea to append data under the lock. It may
> easily cause us to corrupt the file in case the write succeeds
> partially, only.
> 
> Our usual pattern here is to create the lockfile, write all data into
> the new file and then rename it into place.

So here I was also following how `write_one_object()` handles writing its mapping entries. I was trying to keep the `loose_object_idx_merge()` and `write_one_object()` approaches similar. If this really isn't the write approach though, I can explore adapting the patch to follow our more typical pattern.

> I'm also a bit surprised that the file isn't sorted. Is a reader
> expected to always read _all_ mappings?

I was surprised by this too. From my understanding, readers are not expected to consult the "loose-object-idx" file directly, but instead consult an in-memory hash map that is loaded from the file. When an entry is not found in map, the file is reloaded to try to pick up any missing entries.

I see this a preexisting quirk though and am not sure it is something that needs to be addressed as part of this change.

Show 26 quoted lines

> > +	if (fd < 0) {
> > +		ret = error_errno(_("unable to open %s"), dst);
> > +		goto out;
> > +	}
> > +	if (fstat(fd, &st) < 0) {
> > +		ret = error_errno(_("unable to stat %s"), dst);
> > +		goto out;
> > +	}
> > +
> > +	/* Create the loose-object-idx if one does not already exist. */
> > +	if (!st.st_size && write_in_full(fd, loose_object_header,
> > +					 strlen(loose_object_header)) < 0) {
> > +		ret = error_errno(_("failed to write loose object index header"));
> > +		goto out;
> > +	}
> > +
> > +	while (!strbuf_getwholeline(&buf, fp, '\n')) {
> > +		if (write_in_full(fd, buf.buf, buf.len) < 0) {
> > +			ret = error_errno(_("failed to write loose object index %s"),
> > +					  dst);
> > +			goto out;
> > +		}
> > +	}
> 
> When merging, wouldn't we have to verify that the object IDs that we're
> adding don't already exist?

So typically a loose object doesn't get written to the object directory at all if it already exists and thus doesn't create a new mapping entry. There is a race though where concurrent writes of the same object could cause the same entry to be appended twice. This is already an existing problem though as `write_one_object()` also doesn't verify whether the object is already in the file.

With this patch, I mostly avoided many of these preexisting quirks and just focused on addressing the underlying bug. If we feel strongly about it though, I can change the approach.

Thanks, -Justin