Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > Christian Holtje <docwhat@xxxxxxxxx> wrote: > >> I have read all the threads on git having trouble with pread() and I > >> didn't see anything to help. > > ... > >> Receiving objects: 100% (253/253), 5.27 MiB | 9136 KiB/s, done. > >> fatal: cannot pread pack file: No such file or directory > >> fatal: index-pack failed > >> > >> The end of the strace looks like so: > >> pread(3, "", 205, 1373) = 0 > >> write(2, "fatal: cannot pread pack file: N"..., 57) = 57 > > > > Hmmph. So pread for a length of 205 can return 0 on NFS? Is this > > a transient error? If so, perhaps a patch like this might help: ... > > The file shouldn't be short unless someone truncated it, or there > > is a bug in index-pack. Neither is very likely, but I don't think > > we would want to retry pread'ing the same block forever. > > I don't think we would want to retry even once. Return value of 0 from > pread is defined to be an EOF, isn't it? Indeed, it is defined to be EOF, but EOF here makes no sense. We have a file position we saw once before as the start of a delta. We wrote it down to disk. We want to go back and open it up, as we have the base decompressed and in memory and need to compute the SHA-1 of the object that resides at this offset. And *wham* we get an EOF. Where there should be data. Where we know there is data. I'm open to the idea that index-pack has a bug, but I doubt it. We shovel hundreds of megabytes through that on a daily basis across all of the git users, and nobody ever sees it crash out with an EOF in the middle of an object it knows to be present. Except poor Christian on NFS. Actually, I think the last time someone reported something like this in Git it turned out to be an NFS kernel bug. I didn't quote it in my reply to him, but I think he did say this was a linux client, linux server. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
