git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] Don't include devicenumber into INODE_CHANGED test [WAS: Re: running git-update-cache --refresh on different machines on a NFS share always ends up in a lot of io/cpu/time waste]

From
TGThomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date
May 22, 2005, 21:23 UTC
Message-ID
<20050522212312.GC23388@cip.informatik.uni-erlangen.de>
In-Reply-To
<Pine.LNX.4.58.0505221332590.2307@ppc970.osdl.org>
Hello,
> Sorry, I meant "rename", not "link", and yes, it should be NFS-safe. It's 
> how all the mailers do things too, afaik.
okay. I will doublecheck that and come back.
> As to your update-cache problem, it seems to be just due to NFS stat
> caching. You generally should _not_ work on two machines at the same time,
> but it probably does the right thing in the end.

I added some debugging output (see attached patch) and saw that the reason for the invalid thing is that the inode has changed:

... name: pull.h 0x00000010 name: read-cache.c 0x00000010 ...

#define INODE_CHANGED   0x0010

Same problem tla had. It looked at the device number. And of course the device number for NFS shares isn't the same on all machines. So I attached a little patch which fixes the issue for me (and others).

Show 5 quoted lines
> In general, I would suggest using separate GIT repositories over sharing
> them over NFS. As far as I'm concerned, I think NFS should work in the
> sense that you can work from different clients at _different_times_, and
> I'm certainly not going to guarantee that two different clients that work
> at the same time against the same repository will get sane results.

It is more like that I don't remember on which machine I worked last and working accidently on my next free window in screen (and I have a lot of windows). And getting 370 Mbyte over NFS hits my nerves. ;-)

> For example, if you do a "git-checkout-cache -f -a" at the same time, I 
> won't guarantee that things won't race on the working files. Don't do it.

I will not do that. And I will add locking for such operations in my frontend anyway.

	Thomas

CRAP CRAP CRAP: This is just the patch which showed me the debugging output:

diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -174,6 +174,8 @@ static struct cache_entry *refresh_entry
 	if (!changed)
 		return ce;
 
+	fprintf(stderr, "name: %s 0x%08x\n", ce->name, changed);
+
 	/*
 	 * If the mode or type has changed, there's no point in trying
 	 * to refresh the entry - it's not going to match

Here is the real patch:

[PATCH] Don't include devicenumber into INODE_CHANGED test

This fixes the problem that git-update-cache --refresh rebuilds the
cache stat information everytime it is started on a different host while
working in the same NFS shared repository.

Signed-off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>

diff --git a/read-cache.c b/read-cache.c
--- a/read-cache.c
+++ b/read-cache.c
@@ -65,8 +65,7 @@ int ce_match_stat(struct cache_entry *ce
 	if (ce->ce_uid != htonl(st->st_uid) ||
 	    ce->ce_gid != htonl(st->st_gid))
 		changed |= OWNER_CHANGED;
-	if (ce->ce_dev != htonl(st->st_dev) ||
-	    ce->ce_ino != htonl(st->st_ino))
+	if (ce->ce_ino != htonl(st->st_ino))
 		changed |= INODE_CHANGED;
 	if (ce->ce_size != htonl(st->st_size))
 		changed |= DATA_CHANGED;
Previous: Linus TorvaldsNext: Thomas Glanzmann
Message 5 of 8 in “running git-update-cache --refresh on different machines on a NFS share always ends up in a lot of io/cpu/time waste”
  1. Thomas GlanzmannMay 22, 2005
  2. Linus TorvaldsMay 22, 2005
  3. Thomas GlanzmannMay 22, 2005
  4. Linus TorvaldsMay 22, 2005
  5. Don't include devicenumber into INODE_CHANGED test [WAS: Re: running git-update-cache --refresh on different machines on a NFS share always ends up in a lot of io/cpu/time waste]Thomas Glanzmann, May 22, 2005
  6. Alternate Patch: [PATCH] Don't include device number in cache invalidation when running on NFSThomas Glanzmann, May 22, 2005
  7. Linus TorvaldsMay 22, 2005
  8. Thomas GlanzmannMay 22, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.