Re: pread() over NFS (again) [1.5.5.4]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 26, 2008, at 5:05 PM, Shawn O. Pearce wrote:
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.

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!
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux