Full disk behavior of git

Bill Lear· Feb 16, 2007, 16:33 UTC · lore

I wanted to report an error we belatedly uncovered while using 1.4.4.1 to pull into a repo on a disk that filled up. We run a nightly script to build our code base and we did not notice these errors in the build until a few days later.

The build scripts continued to run each evening after this write failure happened, and a subsequent pull showed this:

% git pull
remote: Generating pack...
remote: Done counting 369 objects.
remote: Result has 246 objects.
remote: Deltifying 246 objects.
[...]
remote: Total 246, written 246 (delta 150), reused 190 (delta 95)
error: Could not read 828c0a0649d2d6b43ed13853bba33f7764f034fa
* refs/heads/origin: fast forward to branch 'master' of
ssh+git://source/repos/git/fus
   old..new: ebeb03b..b7e8cd6
error: Could not read 828c0a0649d2d6b43ed13853bba33f7764f034fa
Updating ebeb03b..b7e8cd6
Fast forward
  src/cp/tu.cc                                 |    3 +-
  src/cp/tu.flw.cc                             |   81 +-
  src/cp/tu.plt.cc                             |    3 +-
[...]

and the pull seemed to complete ok.

We checked the repo:

% git-fsck-objects --full error: 08b4bc0910b3e945312e3d0ed3aea77287b61ebf: object not found error: 828c0a0649d2d6b43ed13853bba33f7764f034fa: object not found error: 93edcb9bcaacb3e7caddbcc4188dd5b96ee5c8b2: object not found error: ecf4705ae985133dabdc207d81bd2d9c5a4f1402: object not found dangling commit a7ccd43df37e8c2551358bc32e7341be6a21cb16 dangling tree 2f54a7d7980dac6bb6c4f54e54793e24ef0ac892 dangling tree 9a35dfe6020c361e3fe15bddd2c80d7cbcd665fe dangling tree 0056712d4f15f5bce79743512ec30d8360789a71 dangling tree 899b33309b5a5530e331841eb82d64882b577181

I'm obviously unsure as to what exactly happened, but I did want to point this out in case git should be cleaning up these objects on a failed pull --- not that I think it necessarily should, but I did want to take this as an opportunity to share what is probably a rare failure scenario and let others ponder.

As a final point, our "build master" now informs me that he has been trapping error status from git pull, e.g.:

  git pull || { echo "pull failed"; exit 1; }

however, it appears that the pull read errors above are not resulting in an error status being returned.

Bill

Shawn O. Pearce· Feb 17, 2007, 06:31 UTC · re: Bill Lear · lore

Re: Full disk behavior of git

Bill Lear <rael@zopyra.com> wrote:

Show 7 quoted lines

> As a final point, our "build master" now informs me that he has
> been trapping error status from git pull, e.g.:
> 
>   git pull || { echo "pull failed"; exit 1; }
> 
> however, it appears that the pull read errors above are not resulting
> in an error status being returned.

This was a bug in the 1.4.4.x series. It has been fixed in 1.5.0. Upgrade. :-)

-- 
Shawn.