From: Thomas Glanzmann Date: Sun, 22 May 2005 19:27:34 GMT Subject: Re: running git-update-cache --refresh on different machines on a NFS share always ends up in a lot of io/cpu/time waste Message-ID: <20050522192734.GB23388@cip.informatik.uni-erlangen.de> In-Reply-To: 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