From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E9F0C7EE23 for ; Thu, 1 Jun 2023 11:51:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232915AbjFALvL (ORCPT ); Thu, 1 Jun 2023 07:51:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232667AbjFALvF (ORCPT ); Thu, 1 Jun 2023 07:51:05 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA60A136 for ; Thu, 1 Jun 2023 04:51:01 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-96fd3a658eeso98702566b.1 for ; Thu, 01 Jun 2023 04:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1685620260; x=1688212260; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JHH9IVRD4RODTPYwIZs5ad4p+1OI1MrFohdy2mmlmv8=; b=IN19eBp+DEeoqg2XE3wKTDWjGbsG4E2KNoB2aEX766YoWgKA5CpYwPPoxpoztZ9Fpl WUWG0JRY71wtP+xz5w7u2QTm6kGmsMCfvpwHC+NThMX9S1A8QimqaZCBr3qEarGkexDQ eHK9T9MtAr+da9LKKJuHYvVyKwlJVNAhM5Cak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685620260; x=1688212260; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JHH9IVRD4RODTPYwIZs5ad4p+1OI1MrFohdy2mmlmv8=; b=bbNEoA5Bk84/s1t9vReQpV/kgRECItvNWIoi6JnJ0mAMoCXwsFgwk6NQKJoSs+R4Lo XOqjwWqCG+i9WP8y47/J9hq48MRTaB9OVE6TWKCrz0pwu/K9IXMJt4iF9iEVBnY8S1Wa h7/XAbEJ4Jw/1ioqkoXpq/0K9LGXikYSm8DE0J8OdTHGxNLD+pO3qukOVUDCtZ4ZVsKw +Bpf0uxXQBMlfWKMtoOvebFsTgjM45BbaT7aS5Ubyg+FPrlVuzIotlw2EHA/FGrzgvBk //hjjsrMZ9c8SIxa1nhpLbtTJ/UiABBdr8gaAXEcZSSRdxJqz9zk1oCDdzEgkFHISxNQ qbDQ== X-Gm-Message-State: AC+VfDyGpTrMAx1vMLO36+NgMbQCinIRj1QWvwfhfRVI1oNeB0DCHHo3 p+DxgKGmowDFdvvX31mlWjfRWZWEtQTj/eCayFpoIQ== X-Google-Smtp-Source: ACHHUZ6GzqNSjjLy11eX+Vkvt1lkOi6DgWQU0H8gFw+h4Bq5Ajn3ojurLfNPoI7xR/CrpxFOCqb4csnLnz8httonUjY= X-Received: by 2002:a17:907:7291:b0:96f:4ee4:10d4 with SMTP id dt17-20020a170907729100b0096f4ee410d4mr7779167ejc.43.1685620260403; Thu, 01 Jun 2023 04:51:00 -0700 (PDT) MIME-Version: 1.0 References: <20220517100744.26849-1-dharamhans87@gmail.com> In-Reply-To: From: Miklos Szeredi Date: Thu, 1 Jun 2023 13:50:49 +0200 Message-ID: Subject: Re: [PATCH v5 0/3] FUSE: Implement atomic lookup + open/create To: Bernd Schubert Cc: Dharmendra Singh , Vivek Goyal , "linux-fsdevel@vger.kernel.org" , fuse-devel , "linux-kernel@vger.kernel.org" , Horst Birthelmer Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 1 Jun 2023 at 13:17, Bernd Schubert wrote: > > Hi Miklos, > > On 5/19/22 11:39, Miklos Szeredi wrote: > > On Tue, 17 May 2022 at 12:08, Dharmendra Singh wrote: > >> > >> In FUSE, as of now, uncached lookups are expensive over the wire. > >> E.g additional latencies and stressing (meta data) servers from > >> thousands of clients. These lookup calls possibly can be avoided > >> in some cases. Incoming three patches address this issue. > >> > >> > >> Fist patch handles the case where we are creating a file with O_CREAT. > >> Before we go for file creation, we do a lookup on the file which is most > >> likely non-existent. After this lookup is done, we again go into libfuse > >> to create file. Such lookups where file is most likely non-existent, can > >> be avoided. > > > > I'd really like to see a bit wider picture... > > > > We have several cases, first of all let's look at plain O_CREAT > > without O_EXCL (assume that there were no changes since the last > > lookup for simplicity): > > > > [not cached, negative] > > ->atomic_open() > > LOOKUP > > CREATE > > > > [...] > > > [not cached] > > ->atomic_open() > > OPEN_ATOMIC > > new patch version is eventually going through xfstests (and it finds > some issues), but I have a question about wording here. Why > "OPEN_ATOMIC" and not "ATOMIC_OPEN". Based on your comment @Dharmendra > renamed all functions and this fuse op "open atomic" instead of "atomic > open" - for my non native English this sounds rather weird. At best it > should be "open atomically"? FUSE_OPEN_ATOMIC is a specialization of FUSE_OPEN. Does that explain my thinking? Thanks, Miklos