Re: Holding on to deleted packfiles
Konstantin Ryabitsev wrote: > Well, it may also not be something that's the responsibility of public-inbox > either, e.g. other long-running daemons don't perform such checks. We can just > issue a reload after we've done repacking. The less operational knowledge required, the better; especially since I'd like to see more self-hosted instances pop up. All the dependencies we use become our responsibility, too. Given the lack of response to the libgit2 bug I've found[1], I'm far more inclined to improve git itself. [1] https://bugs.debian.org/975607 https://github.com/libgit2/libgit2/issues/5711 -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
Re: Holding on to deleted packfiles
On Tue, Sep 21, 2021 at 07:06:53PM +, Eric Wong wrote: > Was this from /all/ (ALL.git using batch-file) or Gcf2? I believe this was from Gcf2, though I can't go back and check, unfortunately. > The old stuff has timers to do periodic cleanup, but the new > stuff is trickier as the cost of a restart is higher... > > It should be alright to wire up the old timers to ALL.git with > (hundreds) of inboxes lore currently has. git 2.33+ should be > better when we get into the thousands; but it's still not > great. Well, it may also not be something that's the responsibility of public-inbox either, e.g. other long-running daemons don't perform such checks. We can just issue a reload after we've done repacking. I was just wondering if perhaps you already did something that would recognize that old pack files have gone away. -K
Re: Holding on to deleted packfiles
Konstantin Ryabitsev wrote: > Hello: > > A large git repack job that ran over the weekend revealed a minor problem -- > public-inbox daemon processes will hold on to deleted pack files until they > are restarted. Is there any way to gracefully recognize and handle this > condition? It's not quite benign, as this ended up keeping 40GB+ worth of > inodes from being released. Was this from /all/ (ALL.git using batch-file) or Gcf2? The old stuff has timers to do periodic cleanup, but the new stuff is trickier as the cost of a restart is higher... It should be alright to wire up the old timers to ALL.git with (hundreds) of inboxes lore currently has. git 2.33+ should be better when we get into the thousands; but it's still not great. Gcf2/libgit2 startup time is slow compared to git 2.33+, but I can write a dumb fstat loop to periodically look for st_nlink==0... At some point, I'd like to fix git.git to release packs (and add alternates dynamically) -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
Holding on to deleted packfiles
Hello: A large git repack job that ran over the weekend revealed a minor problem -- public-inbox daemon processes will hold on to deleted pack files until they are restarted. Is there any way to gracefully recognize and handle this condition? It's not quite benign, as this ended up keeping 40GB+ worth of inodes from being released. -K
