From: Jeff King <peff@peff.net>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Shawn Pearce <spearce@spearce.org>,
Nicolas Pitre <nico@fluxnic.net>, Ted Ts'o <tytso@mit.edu>,
Thomas Rast <trast@student.ethz.ch>,
Hallvard B Furuseth <h.b.furuseth@usit.uio.no>,
git@vger.kernel.org
Subject: Re: Keeping unreachable objects in a separate pack instead of loose?
Date: Tue, 12 Jun 2012 15:07:17 -0400 [thread overview]
Message-ID: <20120612190717.GA16911@sigill.intra.peff.net> (raw)
In-Reply-To: <m2fwa0fk0y.fsf@igel.home>
On Tue, Jun 12, 2012 at 08:43:41PM +0200, Andreas Schwab wrote:
> Jeff King <peff@peff.net> writes:
>
> > We could close it in both cases by tweaking the mtime of the file
> > containing the object when we decide not to write because the object
> > already exists.
>
> Though there is always the window between the existence check and the
> mtime update where pruning can hit you.
For the loose object case, you could do them both atomically by calling
utime() on the object, and considering the object to exist only if it
succeeds.
Doing it safely for packs would be harder, though; I think you'd
have to bump the mtime forward, do the search, and then bump it back.
You might err by causing a pack not to be pruned, but that is better
than the opposite.
Unfortunately it gets trickier with network transfers. If somebody is
pushing to your repository, you might tell them you have some set of
objects, then they prepare a pack based on that assumption (which might
take minutes or hours to transfer), and then finally at the end you find
that you actually need the objects in question. Of course, that race is
even harder to trigger, because we do not advertise unreachable objects.
So you would have to have a sequence where the objects are reachable,
the client connects and receives your ref advertisement, then the
objects become unreachable (e.g., due to a simultaneous non-ff push or
deletion), and you do a prune in that interval which removes the
objects. Unlikely, but still possible.
-Peff
next prev parent reply other threads:[~2012-06-12 19:07 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-10 12:31 Keeping unreachable objects in a separate pack instead of loose? Theodore Ts'o
2012-06-10 23:24 ` Hallvard B Furuseth
2012-06-11 14:44 ` Thomas Rast
2012-06-11 15:31 ` Ted Ts'o
2012-06-11 16:08 ` Jeff King
2012-06-11 17:04 ` Nicolas Pitre
2012-06-11 17:45 ` Ted Ts'o
2012-06-11 17:54 ` Jeff King
2012-06-11 18:20 ` Ted Ts'o
2012-06-11 18:43 ` Jeff King
2012-06-11 17:46 ` Jeff King
2012-06-11 17:27 ` Ted Ts'o
2012-06-11 18:34 ` Jeff King
2012-06-11 20:44 ` Hallvard Breien Furuseth
2012-06-11 21:14 ` Jeff King
2012-06-11 21:41 ` Hallvard Breien Furuseth
2012-06-11 21:14 ` Ted Ts'o
2012-06-11 21:39 ` Jeff King
2012-06-11 22:14 ` Ted Ts'o
2012-06-11 22:23 ` Jeff King
2012-06-11 22:28 ` Ted Ts'o
2012-06-11 22:35 ` Jeff King
2012-06-12 0:41 ` Nicolas Pitre
2012-06-12 17:10 ` Jeff King
2012-06-12 17:30 ` Nicolas Pitre
2012-06-12 17:32 ` Jeff King
2012-06-12 17:45 ` Shawn Pearce
2012-06-12 17:50 ` Jeff King
2012-06-12 17:57 ` Nicolas Pitre
2012-06-12 18:43 ` Andreas Schwab
2012-06-12 19:07 ` Jeff King [this message]
2012-06-12 19:09 ` Nicolas Pitre
2012-06-12 19:23 ` Jeff King
2012-06-12 19:39 ` Nicolas Pitre
2012-06-12 19:41 ` Jeff King
2012-06-12 17:55 ` Nicolas Pitre
2012-06-12 17:49 ` Nicolas Pitre
2012-06-12 17:54 ` Jeff King
2012-06-12 18:25 ` Nicolas Pitre
2012-06-12 18:37 ` Ted Ts'o
2012-06-12 19:15 ` Nicolas Pitre
2012-06-12 19:19 ` Ted Ts'o
2012-06-12 19:35 ` Nicolas Pitre
2012-06-12 19:43 ` Ted Ts'o
2012-06-12 19:15 ` Jeff King
2012-06-13 18:17 ` Martin Fick
2012-06-13 21:27 ` Johan Herland
2012-06-11 15:40 ` 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=20120612190717.GA16911@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=h.b.furuseth@usit.uio.no \
--cc=nico@fluxnic.net \
--cc=schwab@linux-m68k.org \
--cc=spearce@spearce.org \
--cc=trast@student.ethz.ch \
--cc=tytso@mit.edu \
/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).