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=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 EF2A21F670 for ; Thu, 10 Mar 2022 12:33:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241959AbiCJMeS (ORCPT ); Thu, 10 Mar 2022 07:34:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238163AbiCJMeR (ORCPT ); Thu, 10 Mar 2022 07:34:17 -0500 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC441723EC for ; Thu, 10 Mar 2022 04:33:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5C6965C0114; Thu, 10 Mar 2022 07:33:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 10 Mar 2022 07:33:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=cc:cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=10jcVH5lsvD3aMySLxXRsG0+nWskwxQSFWAlsT lhB8E=; b=XQOHAasi+/PDe6b4dui9md+BQ39087nqTniOV4yUOMyUBK+xUg2uPx e404gKZyDn0svyTDAxqiZJGRsykuQl46fcS+KHM/CVyMdbN3Lfc5Fouhku2mHK8x k6Zk28mhVL0UROM0tOKyAx55e4dxU13ref8rrOKB/+c9sts9HmoztkywjFNRrxoE +/6KNK6t6JJqnHusHt87bmfpw2l4i7dHz3PH8RFIk1FeelsLFH2OKzznZpmw1RaP Ds10FJVe/ct+v0lh2YvPbw2DC6JMdLrPcpEg98Zb9M/k8SgLoCkfvFBrUG3fpiKd WYIOSVSiaUWAX1LaRBnLFBwrez9uNfIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=10jcVH5lsvD3aMySL xXRsG0+nWskwxQSFWAlsTlhB8E=; b=mA+R9xnkWcCDC0h2hmb4YsbHW8fTfPFiN f2FOAx2aTJl53r4I0s3xI6ngnG/zYO5s9vKRR68AxnLF5l5l8dpdeEAw/bMF/Knn LIrvZVw1JAhMrDVB4HPRdPjTOLZeiuzvHZn2dv5rvbwJlwz+m4rjBKDdGEKjs0bl 6WO6NVLwI1aRGNBiiy93HNu5Agysamh9SqVs3c+g2MSfJYcPVogmBZuo84kHLbJs xKcigBJXhLIRtICi/BVugVhYqjsspYoFfdCDWq24U6cXoar+epQvlVRjYDczK+ne OFWAQPLtd4V7K76QtdN8ONjUsfS9NsVAgZeZOYzqfNQpDiCdq0g8w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddvtddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrrghtrhhi tghkucfuthgvihhnhhgrrhguthcuoehpshesphhkshdrihhmqeenucggtffrrghtthgvrh hnpeehgefhtdefueffheekgfffudelffejtdfhvdejkedthfehvdelgfetgfdvtedthfen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpshesph hkshdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Mar 2022 07:33:11 -0500 (EST) Received: from localhost (ncase [10.192.0.11]) by vm-mail.pks.im (OpenSMTPD) with ESMTPSA id b298b8ac (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 10 Mar 2022 12:33:06 +0000 (UTC) Date: Thu, 10 Mar 2022 13:33:04 +0100 From: Patrick Steinhardt To: Junio C Hamano Cc: Neeraj Singh , Neeraj Singh via GitGitGadget , Git List , "Randall S. Becker" , Bagas Sanjaya , Elijah Newren , =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason , "Neeraj K. Singh" Subject: Re: [PATCH v4 2/4] core.fsync: introduce granular fsync control Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8hKijMTJ6+iJRZ2z" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org --8hKijMTJ6+iJRZ2z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 09, 2022 at 12:03:11PM -0800, Junio C Hamano wrote: > Patrick Steinhardt writes: >=20 > >> If the user cares about fsynching loose object files in the right > >> way, we shouldn't leave loose ref files not following the safe > >> safety level, regardless of how this new core.fsync knobs would look > >> like. > >>=20 > >> I think we three are in agreement on that. > > > > Is there anything I can specifically do to help out with this topic? We > > have again hit data loss in production because we don't sync loose refs > > to disk before renaming them into place, so I'd really love to sort out > > this issue somehow so that I can revive my patch series which fixes the > > known repository corruption [1]. >=20 > How about doing a series to unconditionally sync loose ref creation > and modification? >=20 > Alternatively, we could link it to the existing configuration to > control synching of object files. >=20 > I do not think core.fsyncObjectFiles having "object" in its name is > a good reason not to think those who set it to true only care about > the loose object files and nothing else. It is more sensible to > consider that those who set it to true cares about the repository > integrity more than those who set it to false, I would think. >=20 > But that (i.e. doing it conditionally and choose which knob to use) > is one extra thing that needs justification, so starting from > unconditional fsync_or_die() may be the best way to ease it in. I'd be happy to revive my old patch series, but this kind of depends on where we're standing with the other patch series by Neeraj. If you say that we'll likely not land his patch series for the upcoming release, but a small patch series which only starts to sync loose refs may have a chance, then I'd like to go down that path as a stop-gap solution. Otherwise it probably wouldn't make a lot of sense. Patrick --8hKijMTJ6+iJRZ2z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEF9hrgiFbCdvenl/rVbJhu7ckPpQFAmIp7/8ACgkQVbJhu7ck PpQI6BAAgUcJb/5V5cE9VT0JPaqKCSmZRxu+5FCgwus6VG4Ay7sbanu5bhywFL/g jXNqk7A2X1i7Wl3aXsntQyqkbqwUpjnX7lida25DX2InTKd/vZmypo9EvWjiJCyJ +cffK2kZLeH4HNqZCpYf+u9WaURfX7aDnoNcD6Fpzgai6VKhFgCj4EKyLmlk0cPX kX8h7RHLcOb6iyXeqyPrHJI/zupespgI4LhzYOQ4zSohvzbRNQszVkocxaocEBg+ bQgTB8yWCG9vclbRMxzXz+X+K0OxgOf+Rh6XBgAUtycwpYV4XHApuMU5UsJtPCwY VxLscCvjrKUV6KPJ+K53ULD056DeM9wUSh4RAfSN83M14KS94uMUWADqyYbh4kcf SxkP3BiGIA3jQyNCMEMiIaqAsxvdNbcy/tVRhuGpd4arKAFZc6X/1jAIiIccocJD lWglEMIYYto2F3xo4azB3G2rPQUjGR7dLPau0jz/KqvI8nHgSEwfp1YQLIf8huuT w4I4zvSaaZB3czQ/M6/1XJSYNFCUqbqZDKLRMqMFtZIkChXcsAltjVSaOK4TlPQ1 ebSYvoqBNIhBCu9LV6Z+FedSW8tMagIJ6yXoi4OZe3aL+RIjNOd7BTyK/P6WIe0x YWsnD9gWYlY1b4PMnmnDUsRpUY8VnhjnlFiwTgKjFDtNArn59og= =sPDh -----END PGP SIGNATURE----- --8hKijMTJ6+iJRZ2z--