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: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date: May 22, 2005, 19:27 UTC
Message-ID: <20050522192734.GB23388@cip.informatik.uni-erlangen.de>
In-Reply-To: <Pine.LNX.4.58.0505221205580.2307@ppc970.osdl.org>

Hello,

> It does?

Not for me at the moment:

faui03 -> NFS Server (Solaris 2.9) faui04a -> NFS Client (Solaris 2.9) faui01 -> NFS Client (Linux 2.4.30)

(faui03) [~/work/blastwave] date; time git-update-cache --refresh Sun May 22 21:09:33 CEST 2005

real 1m6.362s user 0m12.550s sys 0m9.200s

(faui04a) [~/work/blastwave] date; time git-update-cache --refresh Sun May 22 21:10:56 CEST 2005

real 1m20.097s user 0m12.270s sys 0m8.930s

(faui01) [~/work/blastwave] date; time git-update-cache --refresh; Sun May 22 21:17:22 CEST 2005

real 0m30.617s user 0m2.340s sys 0m7.970s

> Can you check what

> 	ls -li --time=atime

> shows on the different clients? Also, try "ctime".

atime is different of course different.

(faui01) [~/work/blastwave] (ls -Rli --time=atime; ls -lRi --time=ctime) > ~/faui01 (faui03) [~/work/blastwave] (ls -Rli --time=atime; ls -lRi --time=ctime) > ~/faui03 (faui04a) [~/work/blastwave] (ls -Rli --time=atime; ls -lRi --time=ctime) > ~/faui04a

(faui01) [~/work/blastwave] md5sum ~/faui0{1,3,4a} a2c2cdb38537a54fb74613d1cf6537f0 /home/cip/adm/sithglan/faui01 67aee985bfb7514900a0a1d2c629cec9 /home/cip/adm/sithglan/faui03 67aee985bfb7514900a0a1d2c629cec9 /home/cip/adm/sithglan/faui04a (faui01) [~/work/blastwave] diff -b -u ~/faui01 ~/faui03 --- /home/cip/adm/sithglan/faui01 2005-05-22 21:24:02.000000000 +0200 +++ /home/cip/adm/sithglan/faui03 2005-05-22 21:23:54.000000000 +0200

@@ -1,11 +1,11 @@
 .:
 total 15
 5483033 -rw-r--r--  1 sithglan icipguru  391 May 22 21:14 Makefile
-1842682 drwxr-xr-x  2 sithglan icipguru  512 May 22 21:23 packages/
-5541351 drwxr-xr-x  2 sithglan icipguru  512 May 22 21:23 public_html/
-5541339 drwxr-xr-x  2 sithglan icipguru  512 May 22 21:23 scripts/
-5482949 drwxr-xr-x  2 sithglan icipguru 8704 May 22 21:23 sources/
-5482985 drwxr-xr-x  2 sithglan icipguru 2048 May 22 21:23 specs/
+1842682 drwxr-xr-x    2 sithglan icipguru      512 May 22 21:19 packages/
+5541351 drwxr-xr-x    2 sithglan icipguru      512 May 22 21:19 public_html/
+5541339 drwxr-xr-x    2 sithglan icipguru      512 May 22 21:19 scripts/
+5482949 drwxr-xr-x    2 sithglan icipguru     8704 May 22 21:19 sources/
+5482985 drwxr-xr-x    2 sithglan icipguru     2048 May 22 21:19 specs/

 ./packages:
 total 0

If you need the files:

http://wwwcip.informatik.uni-erlangen.de/~sithglan/faui01  (58k)
http://wwwcip.informatik.uni-erlangen.de/~sithglan/faui03  (61k)
http://wwwcip.informatik.uni-erlangen.de/~sithglan/faui04a (61k)

> It _should_ be safe. It does the old lockfile thing, with a "link()" that
> should guarantee atomicity. No fcntl locking or similar that can have
> problems with networked filesystems and different UNIXes.

Is link() NFS safe? I thought only mkdir() for nfs?

	Thomas