threads / discuss / 10769

git 1.5.3.5 error over NFS

Subject: git 1.5.3.5 error over NFS

## tl;dr

14 messages between Nov 9, 2007 and Nov 14, 2007.

replies: 13people: 4as markdown or json

Bill Lear· Nov 9, 2007, 15:31 UTC · lore
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· Nov 9, 2007, 23:21 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS

Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100:
Show 21 quoted lines
> 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?
Show 5 quoted lines
> 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· Nov 12, 2007, 15:39 UTC · re: Alex Riesen · lore

Re: git 1.5.3.5 error over NFS

On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes:
Show 32 quoted lines
>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
Alex Riesen· Nov 12, 2007, 23:31 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS

Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100:
Show 8 quoted lines
> 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?

Show 32 quoted lines
> >> % 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)?

Alex Riesen· Nov 12, 2007, 23:33 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS

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:
Show 8 quoted lines
> 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?

Show 32 quoted lines
> >> % 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.

Bill Lear· Nov 13, 2007, 14:49 UTC · re: Alex Riesen · lore

Re: git 1.5.3.5 error over NFS

On Tuesday, November 13, 2007 at 00:33:09 (+0100) Alex Riesen writes:
Show 15 quoted lines
>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· Nov 13, 2007, 21:48 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

Bill Lear, Tue, Nov 13, 2007 15:49:20 +0100:
Show 11 quoted lines
> >> >> 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 :)
Show 10 quoted lines
> >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· Nov 13, 2007, 23:56 UTC · re: Alex Riesen · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes:
Show 16 quoted lines
>...
>> >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));

Show 10 quoted lines
>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· Nov 14, 2007, 00:02 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100:
Show 22 quoted lines
> 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· Nov 14, 2007, 00:11 UTC · re: Alex Riesen · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

On Wednesday, November 14, 2007 at 01:02:18 (+0100) Alex Riesen writes:
Show 29 quoted lines
>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
Alex Riesen· Nov 14, 2007, 19:54 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

Bill Lear, Wed, Nov 14, 2007 01:11:30 +0100:
Show 18 quoted lines
> >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).

Nicolas Pitre· Nov 14, 2007, 01:28 UTC · re: Alex Riesen · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

On Wed, 14 Nov 2007, Alex Riesen wrote:
Show 29 quoted lines
> 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· Nov 14, 2007, 01:32 UTC · re: Nicolas Pitre · lore

Re: git 1.5.3.5 error over NFS (pack data corruption)

Nicolas Pitre <nico@cam.org> writes:
Show 9 quoted lines
> 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· Nov 14, 2007, 01:38 UTC · re: Bill Lear · lore

Re: git 1.5.3.5 error over NFS

On Fri, 9 Nov 2007, Bill Lear wrote:
Show 6 quoted lines
> 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

← back to recent threads