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 999101F670; Sat, 16 Oct 2021 09:43:24 +0000 (UTC) Date: Sat, 16 Oct 2021 09:43:24 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: Troubleshooting threads missing from /all/ Message-ID: <20211016094324.GA16488@dcvr> References: <20211001205817.y2h3xypudngkttkj@meerkat.local> <20211001222509.GA1968@dcvr> <20211001231104.lne6aoq7a5hsqi2e@meerkat.local> <20211001234600.GA28791@dcvr> <20211005043954.GA23990@dcvr> <20211005180324.3miboond7ubth5v5@meerkat.local> <20211007213307.29376-0@dcvr> <20211008173336.ftokrvr73vcuhtpg@meerkat.local> <20211008213433.M867097@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211008213433.M867097@dcvr> List-Id: Eric Wong wrote: > Yes. Though given the current situation with missing messages > from /all/, I'd wait until a reindex recovers the missing > messages (and probably a fast fsck checker). I think "public-inbox-extindex --reindex --all --fast" is reasonably ready as an fsck checker. I've been running it a bunch in recent days/weeks and also found+fixed some other bugs along the way. With --fast, --reindex takes around 20 minutes for me with "--batch-size=20m --no-fsync". The first run may take longer if it has stuff to do. But running it repeatedly should not cause it to complain about unseen/stale/mismatched messages (likely the first run will). So it's not /really/ fast, but compared to ~35 hours w/o --fast, then it's alright. Either way, --reindex should be safe with parallel -index and -extindex being run by cronjobs.