git 1.5.3.5 error over NFS

git 1.5.3.5 error over NFS

[Bill Lear]

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

Re: git 1.5.3.5 error over NFS

[Alex Riesen]

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

Re: git 1.5.3.5 error over NFS

[Bill Lear]

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

Re: git 1.5.3.5 error over NFS

[Alex Riesen]

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)?

Re: git 1.5.3.5 error over NFS

[Alex Riesen]

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.

Re: git 1.5.3.5 error over NFS

[Bill Lear]

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

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

[Alex Riesen]

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?

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

[Bill Lear]

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

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

[Alex Riesen]

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 "...

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

[Bill Lear]

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

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

[Nicolas Pitre]

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

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

[Junio C Hamano]

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.

Re: git 1.5.3.5 error over NFS

[Nicolas Pitre]

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

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

[Alex Riesen]

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).