Re: Consolidate SHA1 object file close

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 11, 2008, 17:46 UTC
Message-ID: <alpine.LFD.1.10.0806111037530.3101@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.1.10.0806110952290.3101@woody.linux-foundation.org>

On Wed, 11 Jun 2008, Linus Torvalds wrote:

> 
> Do you have people using special flags for your NFS mounts? And do you 
> know if there is some pattern to the client kernel versions when the 
> problem happens?

Oh, before I even go there - let's get the _really_ obvious case out of the way first.

If you are using a shared git object repository (why are you doing that, btw?), are people perhaps doing things like "git gc --auto" etc at the same time? Perhaps even unknowingly, thanks to autogc?

That's an absolute no-no. It works on a real POSIX filesystem, because even if you unlink a file that is in use by another process, the other process still has access to the data and the file won't be *really* removed until all users have gone away.

That's also true within a _single_ NFS client thanks to so-called "silly-renaming", but it is *not* true across multiple clients.

So if one client is doing some kind of gc and creates a new pack-file and then removes old loose objects, and another client has already looked up and opened that loose object (but not finished reading it), then when the file gets removed, you will literally lose the data on the other client and get a short read!

And nothing we can do can ever fix this very fundamental issue of NFS. NFS simply isn't an even remotely POSIX filesystem, even though it's set up to mostly _look_ like one when accessed from a single client.

In general, I would discourage people ever sharing object directories among multiple users except in a server kind of environment (eg kernel.org).

			Linus