Re: fetching packs and storing them as packs
From: Junio C Hamano <hidden>
Date: 2016-08-11 19:41:50
Shawn Pearce [off-list ref] writes:
So a reader-writer lock is preferred over a non-locking solution such as I posted in http://article.gmane.org/gmane.comp.version-control.git/30288 ?
If you mean these two in your message to be "solution":
So the receive-pack process becomes:
a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
c. Write pack and index.
d. Move pack to $GIT_DIR/objects/pack/...
e. Move index to $GIT_DIR/objects/pack...
f. Update refs.
g. Arrange for new pack and index to be considered active.
And the repack -a -d process becomes:
1. List all active packs and store in memory.
2. Repack only loose objects and objects contained in active packs.
3. Move new pack and idx into $GIT_DIR/objects/pack/...
4. Arrange for new pack and idx to be considered active.
5. Delete active packs found by step #1.
I am not so sure how it solves anything at all.
The race is about this sequence:
- git-receive-pack is spawned from remove git-send-pack;
it lets "index-pack --stdin --fatten" to keep the pack.
- index-pack does its magic and moves the pack and idx
to their final location;
- "repack -a -d" is started by somebody else; it first
remembers all the existing packs; it does the usual
repacking-into-one.
- git-receive-pack that invoked the index-pack waits for
index-pack to finish, and then updates the refs;
- "repack -a -d" is done repacking; removes the packs
that existed when it checked earlier.
Now, I am not sure what your plan to "arrange for new pack and
idx to be considered active" is. Care to explain?
There is a tricky constraints imposed on us by (arguably broken)
commit walkers in that it relies on the (arguably broken)
sha1_file.c:sha1_pack_name() interface, so naming historical
ones $GIT_OBJECT_DIR/pack/hist-X{40}.pack would not work; we
would need to fix commit walkers for that first.