Skip to content

Commit 1c72895

Browse files
Use the same ordering/locking in delete() as C git
Following the examples of cgit, lock packed-refs *before* checking for existance of refs in it [1] and *keep the lock* until the loose ref (if any) is removed [2]. The packed-refs lock is kept even when no packed-refs update is required [3] so that somebody else doesn't pack a reference that we are trying to delete. This fixes a concurrency issue that happens on projects with a substantial amount of refs(>~500k) where packing takes long enough for a ref deletion to be triggered half way through it. Not locking the packed-refs file before checking if the refs exists is not safe, as it opens up situations where loose refs are repacked in memory and locked on disk, but before the lock is released and packed-refs is flushed to disk, a ref is deleted. As packed-refs was NOT locked while checking wether a ref existed in it, the current content on disk was read, which was about to be overwritten and did not contain the ref about to be deleted. As the delete doesn't see the ref in the current, on-disk, version of packed refs, it skips processing altogether and moves on, correctly, deleting only the associated loose ref and leaving the packed one behind. Once the new packed-refs, containing the ref that was just deleted, was commited to disk, the ref would come back to life. Therefore, the packed-refs needs to be locked before checking if it contains a ref or not in the same way the C implementation of Git does at [1]. There are tradeoffs, though, in this decision, which will reduce the parallelism of deleting loose refs and performing the refs repacking, which happens very often in certain JGit implementations like Gerrit Code Review. Before this change, repacking of refs and removal of loose refs unrelated to the in-flight repacking was possible without involving any locking; after this change, all loose refs removals have to wait for the packing of refs to be completed, even though the repacking and the refs removals were completely unrelated and their namespaces disjoint. See more details on the test's performance results and the associated tradeoffs in the Issue jgit-152. NOTE: This delete ref locking logic was incorrect regardless of how the packing of the refs is implemented. Making decisions if the pack transaction is needed or not on an unlocked resource is racy and also flagged as bug at [1]. [1]https://github.com/git/git/blob/master/refs/packed-backend.c#L1590 [2]https://github.com/git/git/blob/master/refs/files-backend.c#L3261 [3]https://github.com/git/git/blob/master/refs/files-backend.c#L2943 Bug: jgit-152 Change-Id: I158ec837904617c5fdf667e295ae667b2f037945
1 parent fc6fd56 commit 1c72895

File tree

1 file changed

+32
-26
lines changed

1 file changed

+32
-26
lines changed

org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/RefDirectory.java

Lines changed: 32 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -678,41 +678,47 @@ void delete(RefDirectoryUpdate update) throws IOException {
678678
}
679679
String name = dst.getName();
680680

681-
// Write the packed-refs file using an atomic update. We might
682-
// wind up reading it twice, before and after the lock, to ensure
683-
// we don't miss an edit made externally.
684-
PackedRefList packed = getPackedRefs();
685-
if (packed.contains(name)) {
686-
inProcessPackedRefsLock.lock();
681+
// Get and keep the packed-refs lock while updating packed-refs and
682+
// removing any loose ref
683+
inProcessPackedRefsLock.lock();
684+
try {
685+
LockFile lck = lockPackedRefsOrThrow();
687686
try {
688-
LockFile lck = lockPackedRefsOrThrow();
689-
try {
687+
// Write the packed-refs file using an atomic update. We might
688+
// wind up reading it twice, before and after checking if the
689+
// ref to delete is included or not, to ensure
690+
// we don't rely on a PackedRefList that is a result of in-memory
691+
// or NFS caching.
692+
PackedRefList packed = getPackedRefs();
693+
if (packed.contains(name)) {
694+
// Force update our packed-refs snapshot before writing
690695
packed = refreshPackedRefs();
691696
int idx = packed.find(name);
692697
if (0 <= idx) {
693698
commitPackedRefs(lck, packed.remove(idx), packed, true);
694699
}
695-
} finally {
696-
lck.unlock();
697700
}
698-
} finally {
699-
inProcessPackedRefsLock.unlock();
700-
}
701-
}
702701

703-
RefList<LooseRef> curLoose, newLoose;
704-
do {
705-
curLoose = looseRefs.get();
706-
int idx = curLoose.find(name);
707-
if (idx < 0)
708-
break;
709-
newLoose = curLoose.remove(idx);
710-
} while (!looseRefs.compareAndSet(curLoose, newLoose));
702+
RefList<LooseRef> curLoose, newLoose;
703+
do {
704+
curLoose = looseRefs.get();
705+
int idx = curLoose.find(name);
706+
if (idx < 0) {
707+
break;
708+
}
709+
newLoose = curLoose.remove(idx);
710+
} while (!looseRefs.compareAndSet(curLoose, newLoose));
711711

712-
int levels = levelsIn(name) - 2;
713-
delete(logFor(name), levels);
714-
if (dst.getStorage().isLoose()) {
715-
deleteAndUnlock(fileFor(name), levels, update);
712+
int levels = levelsIn(name) - 2;
713+
delete(logFor(name), levels);
714+
if (dst.getStorage().isLoose()) {
715+
deleteAndUnlock(fileFor(name), levels, update);
716+
}
717+
} finally {
718+
lck.unlock();
719+
}
720+
} finally {
721+
inProcessPackedRefsLock.unlock();
716722
}
717723

718724
modCnt.incrementAndGet();

0 commit comments

Comments
 (0)