{"thread":{"id":"33018","subject":"gc does not clean up after itself when not enough disk space","startedAt":"2013-02-26T15:38:43Z","lastAt":"2013-02-27T05:07:35Z","messageCount":5,"participants":["jones.noamle","Junio C Hamano","Jens Lehmann","Sitaram Chamarty","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210325","messageId":"512CD703.4080302@gmail.com","threadId":"33018","inReplyTo":"512CD689.4050705@gmail.com","subject":"gc does not clean up after itself when not enough disk space","fromName":"jones.noamle","fromEmail":"lenoam@gmail.com","sentAt":"2013-02-26T15:38:43Z","receivedAt":"2013-02-26T15:38:43Z","isPatch":false,"sender":{"key":"lenoam@gmail.com","avatar":null},"body":"When git gc fails on no more disk space, it leaves tmp_pack files lying \naround that consume whatever space was available (and fill up the disk \nto 100%). Shouldn't git be deleting these files?\n\nRunning git 1.7.9 on cygwin:\n# git --version\ngit version 1.7.9\n# uname -a\nCYGWIN_NT-6.1-WOW64 ---- 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin\n\n\nExample failure output:\n\n# git gc\nCounting objects: 44626, done.\nDelta compression using up to 8 threads.\nCompressing objects: 100% (7756/7756), done.\nfatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No \nspace left on device\nerror: failed to run repack\n\n\nThanks!\nNoam\n"},{"id":"210328","messageId":"7v1uc3njnf.fsf@alter.siamese.dyndns.org","threadId":"33018","inReplyTo":"512CD703.4080302@gmail.com","subject":"Re: gc does not clean up after itself when not enough disk space","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-26T16:07:32Z","receivedAt":"2013-02-26T16:07:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"jones.noamle\" writes:\n\n> # git gc\n> Counting objects: 44626, done.\n> Delta compression using up to 8 threads.\n> Compressing objects: 100% (7756/7756), done.\n> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No\n> space left on device\n\nIn general when we encounter an unexpected error, we tend to try\nleaving things as they are so that we can help diagnosing the\nfailure. But when you ran out of disk space I would agree that it\nmay be sensible to remove a temporary file we didn't manage to write\nout in full.\n"},{"id":"210366","messageId":"512D1B8C.9070506@web.de","threadId":"33018","inReplyTo":"7v1uc3njnf.fsf@alter.siamese.dyndns.org","subject":"Re: gc does not clean up after itself when not enough disk space","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-02-26T20:31:08Z","receivedAt":"2013-02-26T20:31:08Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.02.2013 17:07, schrieb Junio C Hamano:\n> \"jones.noamle\" writes:\n> \n>> # git gc\n>> Counting objects: 44626, done.\n>> Delta compression using up to 8 threads.\n>> Compressing objects: 100% (7756/7756), done.\n>> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No\n>> space left on device\n> \n> In general when we encounter an unexpected error, we tend to try\n> leaving things as they are so that we can help diagnosing the\n> failure. But when you ran out of disk space I would agree that it\n> may be sensible to remove a temporary file we didn't manage to write\n> out in full.\n\nAck. I just recently had to do\n\n git gc || rm -f .git/objects/*/tmp_*\n\nas workaround in the nightly housekeeping script on our CI server.\n"},{"id":"210379","messageId":"CAMK1S_hxZZzi911s2QRpc67sNf_U7Ceo1fPT_hg1gO500pO=6A@mail.gmail.com","threadId":"33018","inReplyTo":"512D1B8C.9070506@web.de","subject":"Re: gc does not clean up after itself when not enough disk space","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-02-27T00:28:20Z","receivedAt":"2013-02-27T00:28:20Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Wed, Feb 27, 2013 at 2:01 AM, Jens Lehmann wrote:\n> Am 26.02.2013 17:07, schrieb Junio C Hamano:\n>> \"jones.noamle\" writes:\n>>\n>>> # git gc\n>>> Counting objects: 44626, done.\n>>> Delta compression using up to 8 threads.\n>>> Compressing objects: 100% (7756/7756), done.\n>>> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No\n>>> space left on device\n>>\n>> In general when we encounter an unexpected error, we tend to try\n>> leaving things as they are so that we can help diagnosing the\n>> failure. But when you ran out of disk space I would agree that it\n>> may be sensible to remove a temporary file we didn't manage to write\n>> out in full.\n>\n> Ack. I just recently had to do\n>\n> git gc || rm -f .git/objects/*/tmp_*\n>\n> as workaround in the nightly housekeeping script on our CI server.\n\nit's not just 'git gc'; a failed push of a large repo (failed due to,\nsay, network issues or whatever) also leave tmp_* lying around. At\nleast as far as I can tell...\n"},{"id":"210381","messageId":"20130227050735.GA10976@sigill.intra.peff.net","threadId":"33018","inReplyTo":"CAMK1S_hxZZzi911s2QRpc67sNf_U7Ceo1fPT_hg1gO500pO=6A@mail.gmail.com","subject":"Re: gc does not clean up after itself when not enough disk space","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-27T05:07:35Z","receivedAt":"2013-02-27T05:07:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 27, 2013 at 05:58:20AM +0530, Sitaram Chamarty wrote:\n\n> > Ack. I just recently had to do\n> >\n> > git gc || rm -f .git/objects/*/tmp_*\n> >\n> > as workaround in the nightly housekeeping script on our CI server.\n> \n> it's not just 'git gc'; a failed push of a large repo (failed due to,\n> say, network issues or whatever) also leave tmp_* lying around. At\n> least as far as I can tell...\n\nYes, we used to run into problems with failed pushes sometimes at\nGitHub. A later `git gc` will clean up the tmp_* objects (via `git\nprune`), but of course we will not run the prune if the repack fails.\nAlso note that a push will just keep receiving objects as long as the\nclient wishes to send them, spooling straight to disk, before any\nenforcement hooks have a chance to run. So on stock git, you could in\ntheory just fill up the receiver's disk, and then git will leave the\nfile sitting around.\n\nI have a patch to make index-pack just do a hard hangup after receiving\n`receive.maximumBytes` bytes (with an appropriate message to stderr).\nIt's not an exact measure of the size of the push (since we need to\ncomplete thin packs, and we may also explode smaller packs), but it at\nleast bounds the size that the sender can push. I'm happy to share the\npatch if others are interested (it's only a few lines).\n\nI've also considered a patch to have index-pack clean up tmp_pack_*\nautomatically on exit, default to off (i.e., the current behavior). A\nbusy site could turn it on globally, and then shut it off for a specific\nrepo when trying to debug a push problem. I find that the leftover\ntmp_pack files are very seldom of interest for forensic debugging. I\nhaven't bothered to write that patch, though; we dropped our prune\nexpiration time well below the 2-week default, so the tmp files get\ncleaned up pretty regularly now.\n\n-Peff\n"}]}