On Thu, 27 Apr 2006, Alex Riesen wrote:
>
> NFS server: 2.6.15
> Client: 2.6.17-rc2
> mount options: tigra:/home /net/home nfs rw,nosuid,nodev,noatime,vers=3,rsize=8192,wsize=32768,hard,intr,proto=udp,timeo=7,retrans=3,addr=tigra 0 0
It's repeatable? Can you check if it goes away if your remove "intr"?
That said, the pack-file should all be written with the "sha1write()"
interface, which is very careful indeed.
I wonder if the _pack-file_ itself might be ok, and the problem is an
index file corruption. For some reason we check the index file first,
which is insane. We should check that the pack-file matches its _own_ SHA1
first, and check the index file second.
So the appended patch would be sensible: before we bother to look at the
index file at all, we should check the pack-file itself.
If it's just the index file that is corrupt, you may even have a chance to
recover the data.
The index file is also written with sha1write(), though, so I really don't
see where it would break. Unless you just simply literally have data
corruption on the server for some strange reason.
Linus
---
diff --git a/pack-check.c b/pack-check.c
index 84ed90d..e575879 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -29,12 +29,12 @@ static int verify_packfile(struct packed
pack_base = p->pack_base;
SHA1_Update(&ctx, pack_base, pack_size - 20);
SHA1_Final(sha1, &ctx);
- if (memcmp(sha1, index_base + index_size - 40, 20))
- return error("Packfile %s SHA1 mismatch with idx",
- p->pack_name);
if (memcmp(sha1, pack_base + pack_size - 20, 20))
return error("Packfile %s SHA1 mismatch with itself",
p->pack_name);
+ if (memcmp(sha1, index_base + index_size - 40, 20))
+ return error("Packfile %s SHA1 mismatch with idx",
+ p->pack_name);
/* Make sure everything reachable from idx is valid. Since we
* have verified that nr_objects matches between idx and pack,
-
: 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