git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org
Subject: Re: [JGIT PATCH 08/10] Scan for new packs if GIT_DIR/objects/pack has been modified
Date: Mon, 20 Apr 2009 18:39:11 -0700	[thread overview]
Message-ID: <20090421013911.GZ23604@spearce.org> (raw)
In-Reply-To: <1240276872-17893-9-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> If GIT_DIR/objects/pack directory has changed then one or more packs
...
> +	@Override
> +	protected boolean tryAgain1() {
> +		final PackFile[] old = packList.get();
> +		if (packDirectoryLastModified <= packDirectory.lastModified()) {

Sadly we needed to use <= here to avoid racy-git cases.  Worse,
unlike with the DirCache we don't have another file system inode
we can use to compare timestamps against.

Consequently, I just realized my commit message isn't entirely
accurate.  In reality we rescan the #F*@!*! directory every time
we have a miss, because the time stamp hasn't changed.

I can't think of another method to use here.  I'd love to avoid
the rescan on a miss if the aren't any new packs in the directory,
but I just don't see how we can do that and avoid the racy-git case
at the same time.

We could try to fudge it by saying < here, but the test cases in
9/10 would then require a Thread.sleep(2) or something to force
enough time to pass for the directory modification time to advance.

I think in real applications, its "good enough" to allow this amount
of fudging.  We shouldn't see more than one repack per repository
per FS clock tick.  And if we do, the admin should be shot on sight.

git-repack is careful to ensure the new pack is linked into the
directory before the old packs are unlinked, so we really shouldn't
ever scan and miss a pack.

-- 
Shawn.

  parent reply	other threads:[~2009-04-21  1:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21  1:21 [JGIT PATCH 00/10] Object access improvements Shawn O. Pearce
2009-04-21  1:21 ` [JGIT PATCH 01/10] Safely handle closing an already closed WindowedFile Shawn O. Pearce
2009-04-21  1:21   ` [JGIT PATCH 02/10] Change empty tree test case to use a temporary repository Shawn O. Pearce
2009-04-21  1:21     ` [JGIT PATCH 03/10] Replace hand-coded read fully loop with NB.readFully Shawn O. Pearce
2009-04-21  1:21       ` [JGIT PATCH 04/10] Clear the reverse index when closing a PackFile Shawn O. Pearce
2009-04-21  1:21         ` [JGIT PATCH 05/10] Introduce a new exception type for an in-place pack modification Shawn O. Pearce
2009-04-21  1:21           ` [JGIT PATCH 06/10] Refactor object database access with new abstraction Shawn O. Pearce
2009-04-21  1:21             ` [JGIT PATCH 07/10] Rescan packs if a pack is modified in-place (part 1) Shawn O. Pearce
2009-04-21  1:21               ` [JGIT PATCH 08/10] Scan for new packs if GIT_DIR/objects/pack has been modified Shawn O. Pearce
2009-04-21  1:21                 ` [JGIT PATCH 09/10] Add test cases for loading new (or replaced) pack files Shawn O. Pearce
2009-04-21  1:21                   ` [JGIT PATCH 10/10] BROKEN TEST: ObjectLoader stays valid across repacks Shawn O. Pearce
2009-04-21 23:16                     ` Robin Rosenberg
2009-04-22 16:33                       ` Shawn O. Pearce
2009-04-22 23:02                       ` Shawn O. Pearce
2009-04-21  2:10                   ` [JGIT PATCH v2 09/10] Add test cases for loading new (or replaced) pack files Shawn O. Pearce
2009-04-21  1:39                 ` Shawn O. Pearce [this message]
2009-04-21  2:08                   ` [JGIT PATCH v2 08/10] Scan for new packs if GIT_DIR/objects/pack has been modified Shawn O. Pearce

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=20090421013911.GZ23604@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=robin.rosenberg@dewire.com \
    /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).