This weekend we're cutting over to use git for our source code control
system. I've imported about 20 years worth of previous history using
"git cvsimport" (takes about four hours). I then cloned the resulting
repository onto five different machines (four Linux, one Solaris).
I've set up a cron job to do a nightly "git fsck" on each of the five
machines, and last night, two of the machines reported fsck errors on
their initial run. Here's a sample of the errors:
error: packed cd00921f75f91985d1b67181632a4764af50d4e8 from
.git/objects/pack/pack-b17f2e0a970084fed1f7a6c7664601e78059063f.pack
is corrupt
error: sha1 mismatch 20abcd833a10aad51ff7f59b6a5e179d77e9a388
error: 20abcd833a10aad51ff7f59b6a5e179d77e9a388: object corrupt or missing
error: sha1 mismatch 343c28f127a5e5b9b85b0bdc5419e131b10ff2f0
...
broken link from tree df17bc72fd5f7cea686f97e14f71f8464149ed25
to blob d085a51be07285bec9ccf0323a7cf47856dbb31f
broken link from tree ab9e5b7383bcde71680abe552e30ae5abf64cf6d
to blob 83e8475441911692d1a63d0272e17d62d1b7b8d1
...
missing blob ad3209e27bbc3676bf06f889779908928948b65a
missing blob 4d4829314e64e2a0524fa520f59f7d18482e2b0a
missing blob 9ed481a1970e5f38b1479241ed21a2296c09cda0
...
The errors reported on these two machines were different, but what's
interesting is that all of the missing blobs refer to various
revisions of the same file, namely our "Changes" file (which is
updated with each change). It's also the largest file in our
repository (3.3M). I immediately started looking at logs to see if
there was any indication of disk corruption and found none (no SMART
errors either). Both of these machines have been stable over a
multi-year period of time (no unexplained crashes). They're also
older Linux machines (running 2.6.5-1.358 and 2.6.1-1.65, with
relatively little memory: 1GB and .5GB), but with newly installed
version of git (1.7.3.1). I initially used git-daemon for the clone
process, but even using ssh, I still see fsck errors on the resulting
clones on these two machines.
If I don't find an explanation for this behavior, our conversion to
git will need to be backed out before development begins tomorrow :-(.
Thanks for any pointers.
Mike.
--
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