Re: [PATCH] gc: support temporarily preserving garbage

From: Jeff King <peff@peff.net>
Date: Nov 18, 2014, 00:21 UTC
Message-ID: <20141118002130.GA3031@peff.net>
In-Reply-To: <CADoxLGMFzujP6kKNpExsCSzQrUrpsgPOcgLmFA_yU7S=NhQorQ@mail.gmail.com>

On Tue, Nov 18, 2014 at 10:59:14AM +1100, Stefan Saasen wrote:

Show 19 quoted lines

> >> I am not sure if this much of code churn is warranted to work around
> >> issues that only happen on repositories on NFS servers that do not
> >> keep open-but-deleted files available.  Is it an option to instead
> >> have a copy of repository locally off NFS?
> >
> > I think it is also not sufficient. This patch seems to cover only
> > objects. But we assume that we can atomically rename() new versions of
> > files into place whenever we like without disrupting existing readers.
> > This is the case for ref updates (and packed-refs), as well as the index
> > file.  The destination end of the rename is an unlink() in disguise, and
> > would be susceptible to the same problems.
> 
> I’m going out on a limb here as my NFS knowledge is rather shallow but a
> rename should be atomic even on NFS.
> 
> "The RENAME operation must be atomic to the client.”
> (https://www.ietf.org/rfc/rfc1813.txt: 3.3.14)
> 
> Does git do something differently here for that not to be the case?

I don't mean the atomicity of the rename itself. But rather what happens to an existing file at the destination of the rename, and processes that have it open. E.g., consider this sequence of events:

  1. Process A calls open("index", O_RDONLY). Possibly it also mmap()s
     the result.

  2. Process B calls open("index.lock", O_WRONLY|O_CREAT|O_EXCL),
     write()s some data to it, and close()s it.

  3. Process B calls rename("index.lock", "index");

Normally, process A's descriptor continues to point to the old "index", and it does not see the new version unless it calls open() again. But on NFS, what happens to process A when it tries to read? I could imagine one of:

  a. It acts like the "unlink" call under discussion. The old file has
     gone away, and anybody who had it mmap'd is going to SIGBUS.

  b. We silently read data from the replacement file. This is bad,
     because we may be in the middle of reading a data structure. We
     expect to get an atomic view of the file once we've opened it.

I don't know which happens, or if it all just works. But it seems like another potential problem point of the same type.

-Peff