From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 5A9211F8C8; Tue, 21 Sep 2021 19:06:53 +0000 (UTC) Date: Tue, 21 Sep 2021 19:06:53 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: Holding on to deleted packfiles Message-ID: <20210921190653.GA16367@dcvr> References: <20210921144754.gulkneuulzo27qbw@meerkat.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210921144754.gulkneuulzo27qbw@meerkat.local> List-Id: 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)