From: Christian Holtje Date: Thu, 26 Jun 2008 21:36:08 GMT Subject: Re: pread() over NFS (again) [1.5.5.4] Message-ID: <20AEFB67-2BE7-470F-B0EA-BDAC4B6DE576@gmail.com> In-Reply-To: <20080626210556.GZ11793@spearce.org> On Jun 26, 2008, at 5:05 PM, Shawn O. Pearce wrote: > Junio C Hamano wrote: >> "Shawn O. Pearce" writes: >>> Christian Holtje 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. I did see the threads that talked about NFS, but I couldn't find any matching messages in the linux kernel mailing list. If someone can give me a pointer to where this picked up on other mailing lists (say, via a URL) then I'll take that back to IT as a reason to upgrade. Would it be a bug in the client or server? I'd assume client... The other NFS/pread() email thread was also a client of linux 2.6.9.... Ciao!