From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) 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.1 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id E84841F453; Sun, 4 Nov 2018 03:50:17 +0000 (UTC) Date: Sun, 4 Nov 2018 03:50:17 +0000 From: Eric Wong To: Yaron Scheffer Cc: Konstantin Ryabitsev , meta@public-inbox.org Subject: Re: Corrupted lkml repo? Message-ID: <20181104035017.rmlr3sf7wybwuvo6@untitled> References: <20181030153806.GB9025@pure.paranoia.local> <20181102203658.otux6kwxsr3wh37y@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Yaron Scheffer wrote: > Eric Wong wrote: > > > Yaron: does disabling smart HTTP to rely on only GET transfers > > improve things? Smart HTTP is great for bandwidth reduction but > > uses more CPU/memory on the server side, and perhaps > > recommending clients do that for big repos is a good thing > > anyways for the initial clone. > > > > GIT_SMART_HTTP=0 git clone --mirror ... > > Maybe, but If "git clone" stresses the server to the point of breakage > as you say, something should be done on the server side. I've been > using the kernel.org repo as Konstantin suggested. Based on Konstantin's message; it didn't seem like the server itself was stressed, just something on Amazon's side. > Perhaps lower the recommended maximum shard size? I didn't hit > this issue with the most recent shard, which is about 50% smaller. That's another option; but migrating/converting existing repos to it would be a flag day and break existing mirrors. ~1G seemed like a reasonable starting point