* git 1.5.3.5 error over NFS @ 2007-11-09 15:31 Bill Lear 2007-11-09 23:21 ` Alex Riesen 2007-11-14 1:38 ` git 1.5.3.5 error over NFS Nicolas Pitre 0 siblings, 2 replies; 14+ messages in thread From: Bill Lear @ 2007-11-09 15:31 UTC (permalink / raw) To: git I've brought this up before, but I don't recall a resolution to it. We have an NFS-mounted filesystem, and git pull is choking on it. % uname -a Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux % git --version git version 1.5.3.5 % git pull remote: Generating pack... remote: Done counting 998 objects. remote: Result has 836 objects. remote: Deltifying 836 objects. remote: 100% (836/836) done Indexing 836 objects... remote: Total 836 (delta 526), reused 688 (delta 380) 100% (836/836) done Resolving 526 deltas... fatal: cannot pread pack file: No such file or directory fatal: index-pack died with error code 128 fatal: Fetch failure: git://source/repo I looked through the archives of this list and did not see a final resolution, other than a suspected bug in the OS NFS code. Do we just need to update our OS? Bill ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS 2007-11-09 15:31 git 1.5.3.5 error over NFS Bill Lear @ 2007-11-09 23:21 ` Alex Riesen 2007-11-12 15:39 ` Bill Lear 2007-11-14 1:38 ` git 1.5.3.5 error over NFS Nicolas Pitre 1 sibling, 1 reply; 14+ messages in thread From: Alex Riesen @ 2007-11-09 23:21 UTC (permalink / raw) To: Bill Lear; +Cc: git Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100: > I've brought this up before, but I don't recall a resolution to it. > > We have an NFS-mounted filesystem, and git pull is choking on it. > > % uname -a > Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux > > % git --version > git version 1.5.3.5 > > % git pull > remote: Generating pack... > remote: Done counting 998 objects. > remote: Result has 836 objects. > remote: Deltifying 836 objects. > remote: 100% (836/836) done > Indexing 836 objects... > remote: Total 836 (delta 526), reused 688 (delta 380) > 100% (836/836) done > Resolving 526 deltas... > fatal: cannot pread pack file: No such file or directory Could you please strace it? With strace -ff? > fatal: index-pack died with error code 128 > fatal: Fetch failure: git://source/repo > > I looked through the archives of this list and did not see a final > resolution, other than a suspected bug in the OS NFS code. Strace, just to be on the safe side ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS 2007-11-09 23:21 ` Alex Riesen @ 2007-11-12 15:39 ` Bill Lear 2007-11-12 23:31 ` Alex Riesen 2007-11-12 23:33 ` Alex Riesen 0 siblings, 2 replies; 14+ messages in thread From: Bill Lear @ 2007-11-12 15:39 UTC (permalink / raw) To: Alex Riesen; +Cc: git On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes: >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100: >> I've brought this up before, but I don't recall a resolution to it. >> >> We have an NFS-mounted filesystem, and git pull is choking on it. >> >> % uname -a >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux >> >> % git --version >> git version 1.5.3.5 >> >> % git pull >> remote: Generating pack... >> remote: Done counting 998 objects. >> remote: Result has 836 objects. >> remote: Deltifying 836 objects. >> remote: 100% (836/836) done >> Indexing 836 objects... >> remote: Total 836 (delta 526), reused 688 (delta 380) >> 100% (836/836) done >> Resolving 526 deltas... >> fatal: cannot pread pack file: No such file or directory > >Could you please strace it? With strace -ff? > >> fatal: index-pack died with error code 128 >> fatal: Fetch failure: git://source/repo >> >> I looked through the archives of this list and did not see a final >> resolution, other than a suspected bug in the OS NFS code. > >Strace, just to be on the safe side Ok, I've done the strace -ff. It has generated 176 strace.out.<pid> files. I have placed a tarball of these files on my home server: http://www.zopyra.com/~rael/git/git-trace.tar.bz2 The file strace.out.25526 has, at the very end: [...] open("/etc/mtab", O_RDONLY) = 4 fstat64(0x4, 0xffff6810) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0x1000) = 0xfffffffff7ffd000 read(4, "/dev/sda1 / ext3 rw 0 0\nnone /pr"..., 4096) = 503 close(4) = 0 munmap(0xf7ffd000, 4096) = 0 open("/proc/meminfo", O_RDONLY) = 4 fstat64(0x4, 0xffff6c7c) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0x1000) = 0xfffffffff7ffd000 read(4, "MemTotal: 16396892 kB\nMemFre"..., 1024) = 672 close(4) = 0 munmap(0xf7ffd000, 4096) = 0 write(2, "Resolving 551 deltas.\n", 22) = 22 pread64(3, "", 242, 541) = 0 write(2, "fatal: ", 7) = 7 write(2, "cannot pread pack file: Success", 31) = 31 write(2, "\n", 1) = 1 exit_group(128) = ? Here is the clipped output of running the strace command: [...] [ Process PID=25347 runs in 32 bit mode. ] umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error [ Process PID=25347 runs in 64 bit mode. ] [ Process PID=25349 runs in 32 bit mode. ] [...] [ Process PID=25366 runs in 64 bit mode. ] [ Process PID=25365 runs in 32 bit mode. ] ptrace: umoven: Input/output error [ Process PID=25366 runs in 64 bit mode. ] [ Process PID=25365 runs in 32 bit mode. ] [...] [ Process PID=25365 runs in 32 bit mode. ] [ Process PID=25366 runs in 64 bit mode. ] ptrace: umoven: Input/output error [ Process PID=25365 runs in 32 bit mode. ] [ Process PID=25366 runs in 64 bit mode. ] [...] [ Process PID=25385 runs in 32 bit mode. ] umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error [...] [ Process PID=25385 runs in 64 bit mode. ] [ Process PID=25482 runs in 32 bit mode. ] [ Process PID=25396 runs in 64 bit mode. ] [ Process PID=25524 runs in 32 bit mode. ] remote: Generating pack... remote: Done counting 1052 objects. remote: Result has 882 objects. remote: Deltifying 882 objects. 100% (882/882) done82) done umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error umovestr: Input/output error Indexing 882 objects. 100% (882/882) done Resolving 551 deltas. remote: Total 882 (delta 551), reused 716 (delta 387) fatal: cannot pread pack file: Success fatal: index-pack died with error code 128 [ Process PID=25522 runs in 64 bit mode. ] Fetch failure: git://source/fusion Bill ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS 2007-11-12 15:39 ` Bill Lear @ 2007-11-12 23:31 ` Alex Riesen 2007-11-12 23:33 ` Alex Riesen 1 sibling, 0 replies; 14+ messages in thread From: Alex Riesen @ 2007-11-12 23:31 UTC (permalink / raw) To: Bill Lear; +Cc: git, nfs, linux-kernel Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100: > On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes: > >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100: > >> I've brought this up before, but I don't recall a resolution to it. > >> > >> We have an NFS-mounted filesystem, and git pull is choking on it. > >> > >> % uname -a > >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux It is a really old kernel... Maybe you could try with some of the recent ones? > >> % git --version > >> git version 1.5.3.5 > >> > >> % git pull > >> remote: Generating pack... > >> remote: Done counting 998 objects. > >> remote: Result has 836 objects. > >> remote: Deltifying 836 objects. > >> remote: 100% (836/836) done > >> Indexing 836 objects... > >> remote: Total 836 (delta 526), reused 688 (delta 380) > >> 100% (836/836) done > >> Resolving 526 deltas... > >> fatal: cannot pread pack file: No such file or directory > > > >Could you please strace it? With strace -ff? > > > >> fatal: index-pack died with error code 128 > >> fatal: Fetch failure: git://source/repo > >> > >> I looked through the archives of this list and did not see a final > >> resolution, other than a suspected bug in the OS NFS code. > > > >Strace, just to be on the safe side > > Ok, I've done the strace -ff. It has generated 176 strace.out.<pid> > files. I have placed a tarball of these files on my home server: > > http://www.zopyra.com/~rael/git/git-trace.tar.bz2 > > The file strace.out.25526 has, at the very end: > Yes, this is the file. I extend the part you quoted. The file is opened here: open(".git/objects/pack_awOTNW", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 write(3, "PACK\0\0\0\2\0\0\3r", 12) = 12 ... lots of data. Counted writes: 488538... write(3, "v\351\247V\325\362\327/\240\265\211\211\322,\261\210\301"..., 4096) = 4096 write(3, "\202\202g\232Bf\211Bf\261Bb\36X\22\4\364\365\25\22\223"..., 1114) = 1114 write(3, "M", 1) = 1 > write(2, "Resolving 551 deltas.\n", 22) = 22 > pread64(3, "", 242, 541) = 0 That's the problem. Hmm... May I kindly suggest moving the topic to linux-nfs (cc-ed along with lk)? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS 2007-11-12 15:39 ` Bill Lear 2007-11-12 23:31 ` Alex Riesen @ 2007-11-12 23:33 ` Alex Riesen 2007-11-13 14:49 ` Bill Lear 1 sibling, 1 reply; 14+ messages in thread From: Alex Riesen @ 2007-11-12 23:33 UTC (permalink / raw) To: Bill Lear; +Cc: git This is the almost same message I cced to lk and nfs, but with Git-interasting parts added. Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100: > On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes: > >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100: > >> I've brought this up before, but I don't recall a resolution to it. > >> > >> We have an NFS-mounted filesystem, and git pull is choking on it. > >> > >> % uname -a > >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux It is a really old kernel... Maybe you could try with some of the recent ones? > >> % git --version > >> git version 1.5.3.5 > >> > >> % git pull > >> remote: Generating pack... > >> remote: Done counting 998 objects. > >> remote: Result has 836 objects. > >> remote: Deltifying 836 objects. > >> remote: 100% (836/836) done > >> Indexing 836 objects... > >> remote: Total 836 (delta 526), reused 688 (delta 380) > >> 100% (836/836) done > >> Resolving 526 deltas... > >> fatal: cannot pread pack file: No such file or directory > > > >Could you please strace it? With strace -ff? > > > >> fatal: index-pack died with error code 128 > >> fatal: Fetch failure: git://source/repo > >> > >> I looked through the archives of this list and did not see a final > >> resolution, other than a suspected bug in the OS NFS code. > > > >Strace, just to be on the safe side > > Ok, I've done the strace -ff. It has generated 176 strace.out.<pid> > files. I have placed a tarball of these files on my home server: > > http://www.zopyra.com/~rael/git/git-trace.tar.bz2 > > The file strace.out.25526 has, at the very end: > Yes, this is the file. I extend the part you quoted. The file is opened here: open(".git/objects/pack_awOTNW", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 write(3, "PACK\0\0\0\2\0\0\3r", 12) = 12 ... lots of data. Counted writes: 488538... write(3, "v\351\247V\325\362\327/\240\265\211\211\322,\261\210\301"..., 4096) = 4096 write(3, "\202\202g\232Bf\211Bf\261Bb\36X\22\4\364\365\25\22\223"..., 1114) = 1114 write(3, "M", 1) = 1 > write(2, "Resolving 551 deltas.\n", 22) = 22 > pread64(3, "", 242, 541) = 0 That's the problem. "Git-interesting parts" > write(2, "fatal: ", 7) = 7 > write(2, "cannot pread pack file: Success", 31) = 31 This is strange. The current git should not produce anything like this (and does not, here). The code in question is: do { ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy); if (n <= 0) die("cannot pread pack file: %s", strerror(errno)); rdy += n; } while (rdy < len); Either your strace or that kernel seem to have clobbered errno, too. > fstat64(0, 0xffff907c) = 0 > open("/etc/mtab", O_RDONLY) = 4 > fstat64(0x4, 0xffff6810) = 0 Interesing. What in git index-pack can read mtab and what for? Is it vanilla Git or have you instrumented it somehow? > [ Process PID=25347 runs in 32 bit mode. ] > umovestr: Input/output error > umovestr: Input/output error Is it your strace? Do you have anything unusual in syslog? BTW, you could try defining NO_PREAD in config.mak, and see if it works the problem around for you. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS 2007-11-12 23:33 ` Alex Riesen @ 2007-11-13 14:49 ` Bill Lear 2007-11-13 21:48 ` git 1.5.3.5 error over NFS (pack data corruption) Alex Riesen 0 siblings, 1 reply; 14+ messages in thread From: Bill Lear @ 2007-11-13 14:49 UTC (permalink / raw) To: Alex Riesen; +Cc: git On Tuesday, November 13, 2007 at 00:33:09 (+0100) Alex Riesen writes: >This is the almost same message I cced to lk and nfs, but with >Git-interasting parts added. > >Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100: >> On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes: >> >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100: >> >> I've brought this up before, but I don't recall a resolution to it. >> >> >> >> We have an NFS-mounted filesystem, and git pull is choking on it. >> >> >> >> % uname -a >> >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux > >It is a really old kernel... Maybe you could try with some of the >recent ones? I'll see if we can: the machine in question is a high security one, and not easy to change. We haven't seen this sort of problem elsewhere on our newer systems as far as I know. >I extend the part you quoted. The file is opened here: >... >This is strange. The current git should not produce anything like >this (and does not, here). ... You are absolutely correct. My comrade ran this with 1.5.0.1 by mistake. He reran the strace with 1.5.3.5, and I have replaced the tarball on my server: http://www.zopyra.com/~rael/git/git-trace.tar.bz2 With this minor correction (!), here is the last part from the last file (strace.out.26001): [...] write(2, "\n", 1) = 1 write(3, "\335\365\205\262RY\360=^h\357\372\274\374_\177\317\357"..., 3712) = 3712 fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 open("/etc/mtab", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=503, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a955fa000 read(4, "/dev/sda1 / ext3 rw 0 0\nnone /pr"..., 4096) = 503 close(4) = 0 munmap(0x2a955fa000, 4096) = 0 open("/proc/meminfo", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a955fa000 read(4, "MemTotal: 16396892 kB\nMemFre"..., 1024) = 672 close(4) = 0 munmap(0x2a955fa000, 4096) = 0 write(2, "Resolving 562 deltas...\n", 24) = 24 rt_sigaction(SIGALRM, {0x40f610, [], SA_RESTORER|SA_RESTART, 0x32c512e2b0}, NULL, 8) = 0 setitimer(ITIMER_REAL, {it_interval={1, 0}, it_value={1, 0}}, NULL) = 0 pread(3, "", 242, 1268) = 0 write(2, "fatal: ", 7) = 7 write(2, "cannot pread pack file: No such "..., 49) = 49 write(2, "\n", 1) = 1 exit_group(128) = ? Sorry for the mistake. I think Linus once commented on an alarm that he found curious in a previous strace I sent for this some time ago ... Bill ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-13 14:49 ` Bill Lear @ 2007-11-13 21:48 ` Alex Riesen 2007-11-13 23:56 ` Bill Lear 0 siblings, 1 reply; 14+ messages in thread From: Alex Riesen @ 2007-11-13 21:48 UTC (permalink / raw) To: Bill Lear; +Cc: git Bill Lear, Tue, Nov 13, 2007 15:49:20 +0100: > >> >> We have an NFS-mounted filesystem, and git pull is choking on it. > >> >> > >> >> % uname -a > >> >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux > > > >It is a really old kernel... Maybe you could try with some of the > >recent ones? > > I'll see if we can: the machine in question is a high security one, > and not easy to change. We haven't seen this sort of problem > elsewhere on our newer systems as far as I know. Suspected that :) > >I extend the part you quoted. The file is opened here: > >... > >This is strange. The current git should not produce anything like > >this (and does not, here). ... > > You are absolutely correct. My comrade ran this with 1.5.0.1 by > mistake. He reran the strace with 1.5.3.5, and I have replaced > the tarball on my server: > > http://www.zopyra.com/~rael/git/git-trace.tar.bz2 Still looks like v1.5.0.1: write(2, "fatal: ", 7) = 7 write(2, "cannot pread pack file: No such "..., 49) = 49 > With this minor correction (!), here is the last part from > the last file (strace.out.26001): I think it got worse: > write(3, "\360]|\204\205\317|\352\336C\342\316\206\334\326\201\211"..., 4096) = 4096 > write(3, "\20\t\33if (cached_vias.insert(die,\227\17"..., 4096) = 4096 The data in packs is zlib-compressed. I don't think you should be able to see any readable strings in them (except for "PACK" in the header). I believe you have a data corruption now. Does git-fsck --all say anything about that, BTW? Besides, could you try with a git compiled with NO_PREAD? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-13 21:48 ` git 1.5.3.5 error over NFS (pack data corruption) Alex Riesen @ 2007-11-13 23:56 ` Bill Lear 2007-11-14 0:02 ` Alex Riesen 0 siblings, 1 reply; 14+ messages in thread From: Bill Lear @ 2007-11-13 23:56 UTC (permalink / raw) To: Alex Riesen; +Cc: git On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes: >... >> >I extend the part you quoted. The file is opened here: >> >... >> >This is strange. The current git should not produce anything like >> >this (and does not, here). ... >> >> You are absolutely correct. My comrade ran this with 1.5.0.1 by >> mistake. He reran the strace with 1.5.3.5, and I have replaced >> the tarball on my server: >> >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2 > >Still looks like v1.5.0.1: > > write(2, "fatal: ", 7) = 7 > write(2, "cannot pread pack file: No such "..., 49) = 49 Well, I just grepped for the above string in git-1.5.3.5: % grep 'cannot pread pack file' *.c index-pack.c: die("cannot pread pack file: %s", strerror(errno)); >I think it got worse: > >> write(3, "\360]|\204\205\317|\352\336C\342\316\206\334\326\201\211"..., 4096) = 4096 >> write(3, "\20\t\33if (cached_vias.insert(die,\227\17"..., 4096) = 4096 > >The data in packs is zlib-compressed. I don't think you should be able >to see any readable strings in them (except for "PACK" in the header). >I believe you have a data corruption now. > >Does git-fsck --all say anything about that, BTW? I'll see if we can run it... >Besides, could you try with a git compiled with NO_PREAD? I'll try this also. Bill ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-13 23:56 ` Bill Lear @ 2007-11-14 0:02 ` Alex Riesen 2007-11-14 0:11 ` Bill Lear 2007-11-14 1:28 ` Nicolas Pitre 0 siblings, 2 replies; 14+ messages in thread From: Alex Riesen @ 2007-11-14 0:02 UTC (permalink / raw) To: Bill Lear; +Cc: git Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100: > On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes: > >... > >> >I extend the part you quoted. The file is opened here: > >> >... > >> >This is strange. The current git should not produce anything like > >> >this (and does not, here). ... > >> > >> You are absolutely correct. My comrade ran this with 1.5.0.1 by > >> mistake. He reran the strace with 1.5.3.5, and I have replaced > >> the tarball on my server: > >> > >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2 > > > >Still looks like v1.5.0.1: > > > > write(2, "fatal: ", 7) = 7 > > write(2, "cannot pread pack file: No such "..., 49) = 49 > > Well, I just grepped for the above string in git-1.5.3.5: > > % grep 'cannot pread pack file' *.c > index-pack.c: die("cannot pread pack file: %s", strerror(errno)); oh, you should be looking for usage.c, the function report (it is called by default die handler). The old code used to fputs("fatal:"), the new just vfprintf's everything, so the write should look like: write(2, "fatal: cannot pread pack file: No such "... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-14 0:02 ` Alex Riesen @ 2007-11-14 0:11 ` Bill Lear 2007-11-14 19:54 ` Alex Riesen 2007-11-14 1:28 ` Nicolas Pitre 1 sibling, 1 reply; 14+ messages in thread From: Bill Lear @ 2007-11-14 0:11 UTC (permalink / raw) To: Alex Riesen; +Cc: git On Wednesday, November 14, 2007 at 01:02:18 (+0100) Alex Riesen writes: >Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100: >> On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes: >> >... >> >> >I extend the part you quoted. The file is opened here: >> >> >... >> >> >This is strange. The current git should not produce anything like >> >> >this (and does not, here). ... >> >> >> >> You are absolutely correct. My comrade ran this with 1.5.0.1 by >> >> mistake. He reran the strace with 1.5.3.5, and I have replaced >> >> the tarball on my server: >> >> >> >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2 >> > >> >Still looks like v1.5.0.1: >> > >> > write(2, "fatal: ", 7) = 7 >> > write(2, "cannot pread pack file: No such "..., 49) = 49 >> >> Well, I just grepped for the above string in git-1.5.3.5: >> >> % grep 'cannot pread pack file' *.c >> index-pack.c: die("cannot pread pack file: %s", strerror(errno)); > >oh, you should be looking for usage.c, the function report (it is >called by default die handler). The old code used to fputs("fatal:"), >the new just vfprintf's everything, so the write should look like: > > write(2, "fatal: cannot pread pack file: No such "... Are you sure? % ls -l git-1.5.3.5.tar.bz2 -rw-r--r-- 1 blear software 1351433 2007-10-31 15:04 git-1.5.3.5.tar.bz2 % bunzip2 -c !$ | tar xf - % cd git-1.5.3.5 % grep -A 5 'void report' usage.c static void report(const char *prefix, const char *err, va_list params) { fputs(prefix, stderr); vfprintf(stderr, err, params); fputs("\n", stderr); } Bill ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-14 0:11 ` Bill Lear @ 2007-11-14 19:54 ` Alex Riesen 0 siblings, 0 replies; 14+ messages in thread From: Alex Riesen @ 2007-11-14 19:54 UTC (permalink / raw) To: Bill Lear; +Cc: git Bill Lear, Wed, Nov 14, 2007 01:11:30 +0100: > >oh, you should be looking for usage.c, the function report (it is > >called by default die handler). The old code used to fputs("fatal:"), > >the new just vfprintf's everything, so the write should look like: > > > > write(2, "fatal: cannot pread pack file: No such "... > > Are you sure? > > % ls -l git-1.5.3.5.tar.bz2 > -rw-r--r-- 1 blear software 1351433 2007-10-31 15:04 git-1.5.3.5.tar.bz2 > % bunzip2 -c !$ | tar xf - > % cd git-1.5.3.5 > % grep -A 5 'void report' usage.c > static void report(const char *prefix, const char *err, va_list params) > { > fputs(prefix, stderr); > vfprintf(stderr, err, params); > fputs("\n", stderr); Ach, right. I just checked Junio's master. BTW, maybe you could check that as well? There were 64bit fixes lately, and had an impression you were using git compiled for 64bit (mmap2 return address from your first strace was shown 64bit). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-14 0:02 ` Alex Riesen 2007-11-14 0:11 ` Bill Lear @ 2007-11-14 1:28 ` Nicolas Pitre 2007-11-14 1:32 ` Junio C Hamano 1 sibling, 1 reply; 14+ messages in thread From: Nicolas Pitre @ 2007-11-14 1:28 UTC (permalink / raw) To: Alex Riesen; +Cc: Bill Lear, git On Wed, 14 Nov 2007, Alex Riesen wrote: > Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100: > > On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes: > > >... > > >> >I extend the part you quoted. The file is opened here: > > >> >... > > >> >This is strange. The current git should not produce anything like > > >> >this (and does not, here). ... > > >> > > >> You are absolutely correct. My comrade ran this with 1.5.0.1 by > > >> mistake. He reran the strace with 1.5.3.5, and I have replaced > > >> the tarball on my server: > > >> > > >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2 > > > > > >Still looks like v1.5.0.1: > > > > > > write(2, "fatal: ", 7) = 7 > > > write(2, "cannot pread pack file: No such "..., 49) = 49 > > > > Well, I just grepped for the above string in git-1.5.3.5: > > > > % grep 'cannot pread pack file' *.c > > index-pack.c: die("cannot pread pack file: %s", strerror(errno)); > > oh, you should be looking for usage.c, the function report (it is > called by default die handler). The old code used to fputs("fatal:"), > the new just vfprintf's everything, so the write should look like: > > write(2, "fatal: cannot pread pack file: No such "... This is not included in 1.5.3.5 though. Nicolas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS (pack data corruption) 2007-11-14 1:28 ` Nicolas Pitre @ 2007-11-14 1:32 ` Junio C Hamano 0 siblings, 0 replies; 14+ messages in thread From: Junio C Hamano @ 2007-11-14 1:32 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Alex Riesen, Bill Lear, git Nicolas Pitre <nico@cam.org> writes: > On Wed, 14 Nov 2007, Alex Riesen wrote: > ... >> oh, you should be looking for usage.c, the function report (it is >> called by default die handler). The old code used to fputs("fatal:"), >> the new just vfprintf's everything, so the write should look like: >> >> write(2, "fatal: cannot pread pack file: No such "... > > This is not included in 1.5.3.5 though. True; although I did not think it was risky at all, I did not think that was serious enough change. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: git 1.5.3.5 error over NFS 2007-11-09 15:31 git 1.5.3.5 error over NFS Bill Lear 2007-11-09 23:21 ` Alex Riesen @ 2007-11-14 1:38 ` Nicolas Pitre 1 sibling, 0 replies; 14+ messages in thread From: Nicolas Pitre @ 2007-11-14 1:38 UTC (permalink / raw) To: Bill Lear; +Cc: git On Fri, 9 Nov 2007, Bill Lear wrote: > I've brought this up before, but I don't recall a resolution to it. > > We have an NFS-mounted filesystem, and git pull is choking on it. > > % uname -a > Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux I recall there was issues with NFS on some old linux version posted on the list a while ago. Again the archive must have it but I'm too lazy to check. Because the issue wasn't reproducible on later kernels, the conclusion was that the kernel was to blame. Nicolas ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2007-11-14 19:54 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-11-09 15:31 git 1.5.3.5 error over NFS Bill Lear 2007-11-09 23:21 ` Alex Riesen 2007-11-12 15:39 ` Bill Lear 2007-11-12 23:31 ` Alex Riesen 2007-11-12 23:33 ` Alex Riesen 2007-11-13 14:49 ` Bill Lear 2007-11-13 21:48 ` git 1.5.3.5 error over NFS (pack data corruption) Alex Riesen 2007-11-13 23:56 ` Bill Lear 2007-11-14 0:02 ` Alex Riesen 2007-11-14 0:11 ` Bill Lear 2007-11-14 19:54 ` Alex Riesen 2007-11-14 1:28 ` Nicolas Pitre 2007-11-14 1:32 ` Junio C Hamano 2007-11-14 1:38 ` git 1.5.3.5 error over NFS Nicolas Pitre
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).