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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id B73AC1F8C6 for ; Sat, 28 Aug 2021 00:20:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232709AbhH1AVo (ORCPT ); Fri, 27 Aug 2021 20:21:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232616AbhH1AVn (ORCPT ); Fri, 27 Aug 2021 20:21:43 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC2FAC0613D9 for ; Fri, 27 Aug 2021 17:20:53 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id i28so14351298ljm.7 for ; Fri, 27 Aug 2021 17:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+besq5dzxo7bTPJcwkS1scBTgpdRMZ9FrOyI59cuid0=; b=H5R5aHZbwvcgwvm8zopBJdkxDiz1eNgoGVpHs8xkyfOfWw734MWqWQd8R/EQ14Ez7L rQB+iLcdpFbA275BKylZwgPNLHdGunoH3CphngaOSda1LWSu54iXOl7ZV8PLJOq6MHXx NrTLXwm4TeTvhkmqV9kU3rOe9v6ACFgvEL0q8CQ2BrrNrgF0P9aruiFbUu/Tit1xjKqG Svpk8F/jxpcn95ajcQ+lbtUXQzlV9ra3OgoJtq0OBQhBP//VbMkjUiJbxityaUshb0WR ZnkO1ZU9F2noqHqrzwY9W5Rfy8ctuRH6OoiTuCwzbhLOgt6e02CSWJyrPSNvKulbrezp lAjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+besq5dzxo7bTPJcwkS1scBTgpdRMZ9FrOyI59cuid0=; b=KYNZ54YHuGCR4Y/3zxhgzJGLsrMdtZGlDdG0jphEQB4pVGZNpLSd+Ars0c+FwGRP8R /c/2tBncNiP1I/lDuJFLhaa7dwLA6rvyk5MCguCsWvmqzx8Q7cP2TVmWYW8J8tLE+88x lVvT7i7ckt5ZubLAbn9yExcao1+Eoopn6LgVTyjHDIzjYrNEOb7lahmMHS56ZfVbmRWJ 8LP5quCM55XQFcGrdWKHAdGtS/g6vQgkYvrcVx9zR8qU73owXXGXZaBca+PrTSjLt/y/ tnjzuXTh39gS4ZVX/l3EP/su+cD9Z03dJzavIn3coRKlP8vgRll8FNivC70MUy7fK2jc US4w== X-Gm-Message-State: AOAM533vDivf1qRweXvqAFMcvupX20zH3Hw1hWBVPSqp51SXm9+Ys1hw O65raHJ8ODu9I3fidAxQ5fxYhMoOIxVYodmzYYs= X-Google-Smtp-Source: ABdhPJzlc0geTTNT1wRiSB0Q45XkxbtwvmWI9Aii6pZwCRGhbXSQUihy7qYkIQSDP9ewVoiIlhFPQcjOTpB1RzLdtKs= X-Received: by 2002:a2e:2a06:: with SMTP id q6mr9702675ljq.424.1630110052276; Fri, 27 Aug 2021 17:20:52 -0700 (PDT) MIME-Version: 1.0 References: <87mtp5cwpn.fsf@evledraar.gmail.com> <20210826055024.GA17178@lst.de> In-Reply-To: <20210826055024.GA17178@lst.de> From: Neeraj Singh Date: Fri, 27 Aug 2021 17:20:44 -0700 Message-ID: Subject: Re: [PATCH 2/2] core.fsyncobjectfiles: batch disk flushes To: Christoph Hellwig Cc: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , Neeraj Singh via GitGitGadget , Git List , Johannes Schindelin , Jeff King , Jeff Hostetler , Neeraj Singh Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Aug 25, 2021 at 10:50 PM Christoph Hellwig wrote: > > On Wed, Aug 25, 2021 at 05:49:45PM -0700, Neeraj Singh wrote: > > One conclusion from reviewing that thread is that as of then, > > sync_file_ranges isn't actually enough > > to make a hard guarantee about writeout occurring. See > > https://lore.kernel.org/linux-fsdevel/20190319204330.GY26298@dastard/. > > My hope is that the Linux FS developers have rectified that shortcoming by now. > > I'm not sure what shortcoming you mean. sync_file_ranges is a system > call that only causes data writeback. It never performs metadata write > back and thus is not an integrity operation at all. That is also very > clearly documented in the man page. > You're right. On re-read of the man page, sync_file_range is listed as an "extremely dangerous" system call. The opportunity in the linux kernel is to offer an alternative set of flags or separate API that allows for an application like Git to separate a metadata writeback request from the disk flush. Separately, I'm hoping I can push from the Windows filesystem side to get a barrier primitive put into the NVME standard so that we can offer more useful behavior to applications rather than these painful hardware flushes.