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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-5.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id BDA5E1F4D7 for ; Fri, 6 May 2022 21:18:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242556AbiEFVVY (ORCPT ); Fri, 6 May 2022 17:21:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1444391AbiEFVVW (ORCPT ); Fri, 6 May 2022 17:21:22 -0400 Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D52B661289 for ; Fri, 6 May 2022 14:17:37 -0700 (PDT) Received: from host-84-13-159-41.opaltelecom.net ([84.13.159.41] helo=[192.168.1.37]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1nn5KR-0005hk-FN; Fri, 06 May 2022 22:17:36 +0100 Message-ID: Date: Fri, 6 May 2022 22:17:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH] Prevent git from rehashing 4GBi files Content-Language: en-GB To: Junio C Hamano Cc: Jason Hatton , =?UTF-8?Q?Ren=c3=a9_Scharfe?= , "git@vger.kernel.org" References: From: Philip Oakley In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 06/05/2022 17:36, Junio C Hamano wrote: >>> + */ >>> +unsigned int munge_st_size(off_t st_size) { >>> + unsigned int sd_size = st_size; >>> + >>> + if(!sd_size && st_size) > Style. Ah, the same line / braces choice (as per coding guidelines). >>> + return 0x80000000; >>> + else >>> + return sd_size; >>> +} > This may treat non-zero multiple of 4GiB as "not racy", but has > anybody double checked the concern Réne brought up earlier that a > 4GiB file that was added and then got rewritten to 2GiB within the > same second would suddenly start getting treated as not racy? This is the pre-existing problem, that ~1in 2^31 size changes might not get noticed for size change. The 0 byte / 4GiB change is an identical issue, as is changing from 3 bytes to 4GiB+3 bytes, etc., so that's no worse than before (well maybe twice as 'unlikely'). > > The patch (the firnal version of it anyway) needs to be accompanied > by a handful of test additions to tickle corner cases like that. They'd be protected by the EXPENSIVE prerequisite I would assume. Any particular test t/txxx that they should be placed in (I'm not that familiar with the test suit) -- Philip