Received: by 2002:a05:6a10:5594:0:0:0:0 with SMTP id ee20csp524713pxb; Mon, 25 Apr 2022 15:34:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzb7EatfpKVyWe/dC/Ud+urKyIXxpL9SV2Px42cb54HXFm9yZ6u1xkXjR10pFqsz6JKWkRr X-Received: by 2002:a62:3083:0:b0:505:f7ac:c4a6 with SMTP id w125-20020a623083000000b00505f7acc4a6mr21266877pfw.66.1650926057785; Mon, 25 Apr 2022 15:34:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650926057; cv=none; d=google.com; s=arc-20160816; b=pw80aosEMH+FdSwscTsoKfq3DG9akEHidBFWVBM39DJLFKVAVIvvydtsLIRc7pkMn2 cCCBYCbrX0PftYSflAHAQDk9MBjNrytxGSyaQ0wmYqJK+f7odHO9NasChEEB/ykr+Rkc D03cFzTbusexop4hIh0En32YfnQJ9uu5mqp0WaO4JyQS33oiha4kwB80aCmuspu+FSWi Ivlhhr1QBQ+3/lEEgQSC7XmvGv00YQ3C0URTQpN5+M/h7ANX66PCCP43ENFczz9j/n9c M/AwgybYnymgBq+EKewYOdecHOmVyqNoXSXAkQmX/UYcKrSu2FWkK2d3blvXv6Ly9Rtl zZQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Gnjzt+1NzH4Eu2LF0ewfanCh28nJVLbVajLnqOyr7so=; b=WT588Xr9RMCT4o7zJSSG0cC9wTTbbBVISZ/rOD9wEkMmFWSDxRXiV1ReRXe2hWF0v5 XIU/CePSBLFdB/otmTztHRXq4iYGuFFqrW3m5HtvTfBxfiLwf1w/x/ccNQZGGU1TdJbT 7xvSrOZRljkuw7u2iOAl/X+cPlAqqIohuibhf/xqQso+axN0bSj0xDxmDEWQCgEVvdPR /09Ew72HUTp95crMEzoR6OLl+1+mWpOSO/kSvycGiq361AZje2dfcgz7L0fH7nk+yZ6a /y/tNLUudDNFbm+IJf0O4NPZvO1xP496QKYded8lNWIREfjT322DS+SQK5vwa1nbb8Ns cmgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=qXgKC+wG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l193-20020a6391ca000000b003ab01935138si7827307pge.47.2022.04.25.15.33.59; Mon, 25 Apr 2022 15:34:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=qXgKC+wG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232664AbiDYNgR (ORCPT + 99 others); Mon, 25 Apr 2022 09:36:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229563AbiDYNgN (ORCPT ); Mon, 25 Apr 2022 09:36:13 -0400 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45F40C04 for ; Mon, 25 Apr 2022 06:33:09 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id d3so9304683ilr.10 for ; Mon, 25 Apr 2022 06:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gnjzt+1NzH4Eu2LF0ewfanCh28nJVLbVajLnqOyr7so=; b=qXgKC+wGX6JUjSmbOLeCpcvFuKT0dg8qOs6PnXS15L5ncoNkRtCqiDgePn75kofNgm 2tCSFz+93T4dTrz5WENecqA044vqKd79ROI43d4bZZc4lYwpp1E6NtPVnFW/Nr856ujx eat6iqRyEdXPWA3l2TbnFnebo8PX4ga3C+QuE80EqcZeEI1lw0U4OhFE2w/O6uododXg 0rfhGvGLA3PN9blzFmc5i9gJ6FrbEu0nqfBO7cwR94h5AUXuLo4iPSwDjkLR74tBNBdp HNPvsRj8bOhtz/3WzQ42aQrJRE5GhZsW+JMGRBDC3ZoVy4CUUMyGjrgHcl6z91GHd5rQ 32JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gnjzt+1NzH4Eu2LF0ewfanCh28nJVLbVajLnqOyr7so=; b=FEDMkqpEG0q3eB4nAtsYrmFcgPel+ls7OLOt/o58ECmRpj0BMxdLpnHtdofkPw7yNR JEFYtXzhJbyH7Kf8t3kqndKWUrFFpvLKGU3cUEsGVEI1j5nyuid0WCsjFGF0fEXEoRVc hpKfmYP/5WJEE4yVEKT8gqKHPp8v0GJQOTv3C05V12nNA9IkoaiqdZbAAgz6lpEGfur1 uvbSxnQmR4wZ6BjUhTJsHT1KJK9YSojuurHY2ykUwUbzzxR1m5kTseNzM6sJL9zPtVCL Il+UrrF+zZLlDL5ttja3W1U92SQJ/knYdPdABP+etfvmR2nxibDCyncJf3F5uQjF/2XT oAhg== X-Gm-Message-State: AOAM531ojZK7KauQjqygNbfhKWlJr/9jydtqHuUFKQOIrlb0ujUfyLFH 8FBPr/XzfsVlEPgGp7E8OzgDFClogXNemG74E45MaChws82gaQ== X-Received: by 2002:a05:6e02:f52:b0:2ca:95e4:f4b5 with SMTP id y18-20020a056e020f5200b002ca95e4f4b5mr5918655ilj.240.1650893588740; Mon, 25 Apr 2022 06:33:08 -0700 (PDT) MIME-Version: 1.0 References: <20220325132126.61949-1-zhangjiachen.jaycee@bytedance.com> In-Reply-To: From: Jiachen Zhang Date: Mon, 25 Apr 2022 21:32:57 +0800 Message-ID: Subject: Re: Re: [RFC PATCH] fuse: support cache revalidation in writeback_cache mode To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Xie Yongji Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 25, 2022 at 8:41 PM Miklos Szeredi wrote: > > On Fri, 25 Mar 2022 at 14:23, Jiachen Zhang > wrote: > > > > Hi all, > > > > This RFC patch implements attr cache and data cache revalidation for > > fuse writeback_cache mode in kernel. Looking forward to any suggestions > > or comments on this feature. > > Quick question before going into the details: could the cache > revalidation be done in the userspace filesystem instead, which would > set/clear FOPEN_KEEP_CACHE based on the result of the revalidation? > > Thanks, > Miklos Hi, Miklos, Thanks for replying. Yes, I believe we can also perform the revalidation in userspace, and we can invalidate the data cache with FOPEN_KEEP_CACHE cleared. But for now, there is no way we can invalidate attr cache (c/mtime and size) in writeback mode. If it is more concise to implement most of the logic in userspace, do you think we should add a flag for attr cache just like what FOPEN_KEEP_CACHE does for data cache? Thanks, Jiachen