On Jun 26, 2008, at 1:56 PM, Junio C Hamano wrote:
"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?
No, it seems to be a simple error-out in this case. We have 2.4.20
systems with nfs-utils 0.3.3 and used to frequently get the same error
while pushing. I made a similar change back in February and haven't
had a problem since:
diff --git a/index-pack.c b/index-pack.c
index 5ac91ba..85c8bdb 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -313,7 +313,14 @@ static void *get_data_from_pack(struct
object_entry *obj)
src = xmalloc(len);
data = src;
do {
+ // It appears that if multiple threads read across NFS, the
+ // second read will fail. I know this is awful, but we wait for
+ // a little bit and try again.
ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
+ if (n <= 0) {
+ sleep(1);
+ n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
+ }
if (n <= 0)
die("cannot pread pack file: %s", strerror(errno));
rdy += n;
I use a sleep request since it seems less likely that the other thread
will have an outstanding request after a second of waiting.
--
Logan Kennelly
,,,
(. .)
--ooO-(_)-Ooo--
--
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
