# git 1.5.3.5 error over NFS 14 messages from 2007-11-09 to 2007-11-14. Participants: Bill Lear, Alex Riesen, Nicolas Pitre, Junio C Hamano. Thread: https://gitlist.dev/t/10769 ## Bill Lear, 2007-11-09 15:31 Subject: git 1.5.3.5 error over NFS Message-ID: <18228.32091.865519.312011@lisa.zopyra.com> URL: https://gitlist.dev/e/18228.32091.865519.312011%40lisa.zopyra.com ``` 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 ``` ## Alex Riesen, 2007-11-09 23:21 Subject: Re: git 1.5.3.5 error over NFS Message-ID: <20071109232106.GA3435@steel.home> URL: https://gitlist.dev/e/20071109232106.GA3435%40steel.home In-Reply-To: <18228.32091.865519.312011@lisa.zopyra.com> ``` 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 ``` ## Bill Lear, 2007-11-12 15:39 Subject: Re: git 1.5.3.5 error over NFS Message-ID: <18232.29603.856766.275854@lisa.zopyra.com> URL: https://gitlist.dev/e/18232.29603.856766.275854%40lisa.zopyra.com In-Reply-To: <20071109232106.GA3435@steel.home> ``` 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. 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 ``` ## Alex Riesen, 2007-11-12 23:31 Subject: Re: git 1.5.3.5 error over NFS Message-ID: <20071112233103.GH2918@steel.home> URL: https://gitlist.dev/e/20071112233103.GH2918%40steel.home In-Reply-To: <18232.29603.856766.275854@lisa.zopyra.com> ``` 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. > 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)? ``` ## Alex Riesen, 2007-11-12 23:33 Subject: Re: git 1.5.3.5 error over NFS Message-ID: <20071112233309.GI2918@steel.home> URL: https://gitlist.dev/e/20071112233309.GI2918%40steel.home In-Reply-To: <18232.29603.856766.275854@lisa.zopyra.com> ``` 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. > 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. ``` ## Bill Lear, 2007-11-13 14:49 Subject: Re: git 1.5.3.5 error over NFS Message-ID: <18233.47472.890658.729250@lisa.zopyra.com> URL: https://gitlist.dev/e/18233.47472.890658.729250%40lisa.zopyra.com In-Reply-To: <20071112233309.GI2918@steel.home> ``` 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 ``` ## Alex Riesen, 2007-11-13 21:48 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: <20071113214802.GH3268@steel.home> URL: https://gitlist.dev/e/20071113214802.GH3268%40steel.home In-Reply-To: <18233.47472.890658.729250@lisa.zopyra.com> ``` 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? ``` ## Bill Lear, 2007-11-13 23:56 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: <18234.14781.55429.671459@lisa.zopyra.com> URL: https://gitlist.dev/e/18234.14781.55429.671459%40lisa.zopyra.com In-Reply-To: <20071113214802.GH3268@steel.home> ``` 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 ``` ## Alex Riesen, 2007-11-14 00:02 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: <20071114000218.GL3268@steel.home> URL: https://gitlist.dev/e/20071114000218.GL3268%40steel.home In-Reply-To: <18234.14781.55429.671459@lisa.zopyra.com> ``` 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 "... ``` ## Bill Lear, 2007-11-14 00:11 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: <18234.15666.711624.443184@lisa.zopyra.com> URL: https://gitlist.dev/e/18234.15666.711624.443184%40lisa.zopyra.com In-Reply-To: <20071114000218.GL3268@steel.home> ``` 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 ``` ## Nicolas Pitre, 2007-11-14 01:28 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.9999.0711132027430.21255%40xanadu.home In-Reply-To: <20071114000218.GL3268@steel.home> ``` 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 ``` ## Junio C Hamano, 2007-11-14 01:32 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: <7vfxz9pq7d.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vfxz9pq7d.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Nicolas Pitre 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. ``` ## Nicolas Pitre, 2007-11-14 01:38 Subject: Re: git 1.5.3.5 error over NFS Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.9999.0711132030370.21255%40xanadu.home In-Reply-To: <18228.32091.865519.312011@lisa.zopyra.com> ``` 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 ``` ## Alex Riesen, 2007-11-14 19:54 Subject: Re: git 1.5.3.5 error over NFS (pack data corruption) Message-ID: <20071114195406.GB3973@steel.home> URL: https://gitlist.dev/e/20071114195406.GB3973%40steel.home In-Reply-To: <18234.15666.711624.443184@lisa.zopyra.com> ``` 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). ```