Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, 2017-02-08 at 09:44 -0800, Junio C Hamano wrote: > Duy Nguyen writes: > > > On second thought, perhaps gc.autoDetach should default to false if > > there's no tty, since its main point it to stop breaking interactive > > usage. That would make the server side happy (no

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, Feb 08, 2017 at 04:18:25PM -0800, Junio C Hamano wrote: > > We wrote something similar at GitHub, too, but we never ended up using > > it in production. We found that with a sane scheduler, it's not too big > > a deal to just do maintenance once in a while. > > Thanks again for this.

Re: "disabling bitmap writing, as some objects are not being packed"?

Jeff King writes: > In my experience, auto-gc has never been a low-maintenance operation on > the server side (and I do think it was primarily designed with clients > in mind). I do not think auto-gc was ever tweaked to help server usage, in its history since it was invented

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, Feb 08, 2017 at 05:14:03PM -0500, David Turner wrote: > > I wonder if you'd want to either bump the auto-gc object limit, or > > possibly reduce the gc.pruneExpire limit to keep this situation from > > coming up in the first place (or at least mitigating the amount of time > > it's the

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, 2017-02-08 at 14:08 -0500, Jeff King wrote: > On Wed, Feb 08, 2017 at 02:05:42PM -0500, David Turner wrote: > > > On Wed, 2017-02-08 at 09:44 -0800, Junio C Hamano wrote: > > > Duy Nguyen writes: > > > > > > > On second thought, perhaps gc.autoDetach should default to

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, Feb 08, 2017 at 02:05:42PM -0500, David Turner wrote: > On Wed, 2017-02-08 at 09:44 -0800, Junio C Hamano wrote: > > Duy Nguyen writes: > > > > > On second thought, perhaps gc.autoDetach should default to false if > > > there's no tty, since its main point it to stop

Re: "disabling bitmap writing, as some objects are not being packed"?

Duy Nguyen writes: > On second thought, perhaps gc.autoDetach should default to false if > there's no tty, since its main point it to stop breaking interactive > usage. That would make the server side happy (no tty there). Sounds like an idea, but wouldn't that keep the

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, Feb 8, 2017 at 3:24 PM, David Turner wrote: > On Wed, 2017-02-08 at 13:45 +0700, Duy Nguyen wrote: >> On Wed, Feb 8, 2017 at 8:03 AM, David Turner wrote: >> > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: >> >> And we can't grep for fatal

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, 2017-02-08 at 13:45 +0700, Duy Nguyen wrote: > On Wed, Feb 8, 2017 at 8:03 AM, David Turner wrote: > > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: > >> And we can't grep for fatal errors anyway. The problem that led to > >> 329e6e8794 was this line > >> > >>

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, Feb 8, 2017 at 8:03 AM, David Turner wrote: > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: >> And we can't grep for fatal errors anyway. The problem that led to >> 329e6e8794 was this line >> >> warning: There are too many unreachable loose objects; run

Re: "disabling bitmap writing, as some objects are not being packed"?

On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: > And we can't grep for fatal errors anyway. The problem that led to > 329e6e8794 was this line > > warning: There are too many unreachable loose objects; run 'git > prune' to remove them. > > which is not fatal. So, speaking of that

Re: "disabling bitmap writing, as some objects are not being packed"?

On Sat, Dec 17, 2016 at 4:28 AM, Junio C Hamano <gits...@pobox.com> wrote: > David Turner <nova...@novalis.org> writes: > >> I'm a bit confused by the message "disabling bitmap writing, as some >> objects are not being packed". I see it the my gc.log file o

Re: "disabling bitmap writing, as some objects are not being packed"?

On Fri, Dec 16, 2016 at 04:40:16PM -0500, David Turner wrote: > I would assume, based on the documentation, that auto gc would be doing > an all-into-one repack: > "If the number of packs exceeds the value of gc.autopacklimit, then > existing packs (except those marked with a .keep file) are >

Re: "disabling bitmap writing, as some objects are not being packed"?

On Fri, 2016-12-16 at 16:32 -0500, Jeff King wrote: > On Fri, Dec 16, 2016 at 01:28:00PM -0800, Junio C Hamano wrote: > > > > 2. I don't understand what would cause that message. That is, what bad > > > thing am I doing that I should stop doing? I've briefly skimmed the > > > code and commit

Re: "disabling bitmap writing, as some objects are not being packed"?

On Fri, Dec 16, 2016 at 01:28:00PM -0800, Junio C Hamano wrote: > > 2. I don't understand what would cause that message. That is, what bad > > thing am I doing that I should stop doing? I've briefly skimmed the > > code and commit message, but the answer isn't leaping out at me. > > Enabling

Re: "disabling bitmap writing, as some objects are not being packed"?

On Fri, Dec 16, 2016 at 04:05:31PM -0500, David Turner wrote: > 1. Its presence in the gc.log file prevents future automatic garbage > collection. This seems bad. I understand the desire to avoid making > things worse if a past gc has run into issues. But this warning is > non-fatal; the only

Re: "disabling bitmap writing, as some objects are not being packed"?

David Turner <nova...@novalis.org> writes: > I'm a bit confused by the message "disabling bitmap writing, as some > objects are not being packed". I see it the my gc.log file on my git > server. > 1. Its presence in the gc.log file prevents future automatic garbage &

"disabling bitmap writing, as some objects are not being packed"?

I'm a bit confused by the message "disabling bitmap writing, as some objects are not being packed". I see it the my gc.log file on my git server. 1. Its presence in the gc.log file prevents future automatic garbage collection. This seems bad. I understand the desire to avoid mak