Re: Troubleshoot clone issue to NFS.

From: Jeff King <peff@peff.net>
Date: Jun 5, 2015, 12:18 UTC
Message-ID: <20150605121817.GA22125@peff.net>
In-Reply-To: <7FAE15F0A93C0144AD8B5FBD584E1C55197764FE@C111KXTEMBX51.ERF.thomson.com>

On Fri, Jun 05, 2015 at 12:01:16PM +0000, steve.norman@thomsonreuters.com wrote:

Show 15 quoted lines

> On Sunday, May 24, 2015 @ 10:01 AM Duy Nguyen [mailto:pclouds@gmail.com] did scribble:
> 
> > In case you want to back away from option 2 because it starts to leak
> > raciness, which your old commit tried to fix in the first place. I
> > think the only other place that tests for lots of non-existent loose
> > objects is write_sha1_file (e.g. "tar -xf bigtarball.tar.gz; cd
> > bigtarball; git init; git add ."). But the number of calls should be
> > much smaller compared to index-pack and it does not use has_sha1_file,
> > it uses check_and_freshen_file() instead.
> > 
> > There are other places where has_sha1_file() may return 0, but I think
> > the number of calls is even smaller to bother (shallow.c,
> > fetch-pack.c, apply.c, buik-checkin.c)
> 
> Any updates / further thoughts on this?

Sorry, I haven't had a chance to look at it further. It still on my todo list. My plan is:

  1. Devise some torture to tests to see whether my patch series is in
     fact racy on Linux.

  2. Assuming it is, scrap it and make a has_sha1_file_quick() which
     might sometimes return a false negative (if somebody else is
     repacking). Use that in index-pack (and possibly other places, but
     we can start with index-pack).

If we skip step 1 out of pessimism (which I think is a reasonable thing to do), then step 2 should not be all that much work. I'm going to be offline for a few days, though, so I won't get to it until next week at the earliest. If you (or someone else) wants to take a stab at it, please feel free.

-Peff