Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6180036iog; Thu, 23 Jun 2022 13:02:50 -0700 (PDT) X-Google-Smtp-Source: AGRyM1usEaW78Dl7V3oLBCxJxLi0DrtZ44KiTYXlVZzt0kyQ0lq4bABJPaHCijDKwwT4pl8gNlNm X-Received: by 2002:a62:3105:0:b0:51c:b8b9:7965 with SMTP id x5-20020a623105000000b0051cb8b97965mr42303551pfx.65.1656014570585; Thu, 23 Jun 2022 13:02:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656014570; cv=none; d=google.com; s=arc-20160816; b=ZafR2j0VBRXdl6pygUdxvy4faUGxlRO8yIraFObHQquDEE3/yQDQGkFpd2as6WBxtJ e6OjsNUbBb3pnip79gW089SqjixIleeQXtjlqTIf15Qz9K44u4GOxqEWIKPn2fcyL8A7 vQ+ypsgZWbeF/2rud8zdS9OmpgvfE9t5dSjoie4m7P79QkN9xgPjQ7JezIHOCuIelqdr yCTca1fUYD0Kknc56DVqf+dxINMfyaB+YCaKjh2v/dY2zovZw73r33BqBr6fi/09kii8 XBwTAZNkLO00gGCs+aPz0vxW4vgUxhQk1F5wplaOgk+7INM2wcC/xPlEqmSP+Dir34yA 3h4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=PeNVREv1NWyeUggZHOzWT8IR8BLdwJfkFs5TG9nYZK4=; b=J9IY0w3LJgAvWyPcvI8dtMAKon3c5VBslgYIOCczAdsSKs3U9GwzohiXdGZ+pNNa1W keqf6pp2mEUaCDCQvZCJlgw+dgG4yCoecare0XUNRP2aYOsWB4X/aOOG7hhwTiptJF20 3ScolTMvi/RrY0e4z3/8k0x/WDfKX0O7g82pa6q99x5W+6asvEN7qupqbey1CT3nfFTg 1XEg/RizgPmiGa8vaUl7B/G2g4h/lF7+MlPox4xXBGBg8MsVxaYSg62rt3VchAk0BCzo WgvFkrQEEwfPIsLOQkwSzMU8HFgaDpLANpvMTZXOoslFZbgOHYMHeQ3+LlfbkAykNvZW FjSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IP7LIolu; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jd9-20020a170903260900b0016a1e0cabdbsi533731plb.75.2022.06.23.13.02.38; Thu, 23 Jun 2022 13:02:50 -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=@redhat.com header.s=mimecast20190719 header.b=IP7LIolu; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230022AbiFWTZg (ORCPT + 99 others); Thu, 23 Jun 2022 15:25:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbiFWTZV (ORCPT ); Thu, 23 Jun 2022 15:25:21 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C650052E7F for ; Thu, 23 Jun 2022 11:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656009521; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PeNVREv1NWyeUggZHOzWT8IR8BLdwJfkFs5TG9nYZK4=; b=IP7LIolubL355ccY85YZy5C9Uu36gqiMebOF6gLXe5GL5VjbWYI1MrlL9ok+2jOj7S6y32 OS/KoXcwH6fJlT2pUZYe0Ufx9BNsjiO/QmO5WMgZCdF07V5HFOccDFhZBg33ujGBfDZQth dHRFxI6es0+sh8scmHM/+3iWfZ0scpE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-240-C68Z2qpLNROBPtNyCW2cFA-1; Thu, 23 Jun 2022 14:38:37 -0400 X-MC-Unique: C68Z2qpLNROBPtNyCW2cFA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 26EB33806700; Thu, 23 Jun 2022 18:38:37 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.18.106]) by smtp.corp.redhat.com (Postfix) with ESMTP id 17ADA141510C; Thu, 23 Jun 2022 18:38:37 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id CD8682209F9; Thu, 23 Jun 2022 14:38:36 -0400 (EDT) Date: Thu, 23 Jun 2022 14:38:36 -0400 From: Vivek Goyal To: wubo <11123156@vivo.com> Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Wu Bo Subject: Re: [PATCH] fuse: force sync attr when inode is invalidated Message-ID: References: <20220621125651.14954-1-11123156@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220621125651.14954-1-11123156@vivo.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Tue, Jun 21, 2022 at 08:56:51PM +0800, wubo wrote: > From: Wu Bo > > Now the fuse driver only trust it's local inode size when > writeback_cache is enabled. Even the userspace server tell the driver > the inode cache is invalidated, the size attrabute will not update. And > will keep it's out-of-date size till the inode cache is dropped. This is > not reasonable. BTW, can you give more details about what's the use case. With writeback_cache, writes can be cached in fuse and not sent to file server immediately. And I think that's why fuse trusts local i_size. With writeback_cache enabled, I don't think file should be modified externally (outside the fuse client). So what's that use case where file size cached in fuse is out of date. You probably should not use writeback_cache if you are modifying files outside the fuse client. Having said that I am not sure why FUSE_NOTIFY_INVAL_INODE was added to begin with. If files are not supposed to be modifed outside the fuse client, why are we dropping acls and invalidating attrs. If intent is just to drop page cache, then it should have been just that nothing else. So up to some extent, FUSE_NOTIFY_INVAL_INODE is somewhat confusing. Would have been good if there was some documentation for it. Thanks Vivek > > Signed-off-by: Wu Bo > --- > fs/fuse/inode.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c > index 8c0665c5dff8..a4e62c7f2b83 100644 > --- a/fs/fuse/inode.c > +++ b/fs/fuse/inode.c > @@ -162,6 +162,11 @@ static ino_t fuse_squash_ino(u64 ino64) > return ino; > } > > +static bool fuse_force_sync(struct fuse_inode *fi) > +{ > + return fi->i_time == 0; > +} > + > void fuse_change_attributes_common(struct inode *inode, struct fuse_attr *attr, > u64 attr_valid, u32 cache_mask) > { > @@ -222,8 +227,10 @@ void fuse_change_attributes_common(struct inode *inode, struct fuse_attr *attr, > u32 fuse_get_cache_mask(struct inode *inode) > { > struct fuse_conn *fc = get_fuse_conn(inode); > + struct fuse_inode *fi = get_fuse_inode(inode); > + bool is_force_sync = fuse_force_sync(fi); > > - if (!fc->writeback_cache || !S_ISREG(inode->i_mode)) > + if (!fc->writeback_cache || !S_ISREG(inode->i_mode) || is_force_sync) > return 0; > > return STATX_MTIME | STATX_CTIME | STATX_SIZE; > @@ -437,6 +444,7 @@ int fuse_reverse_inval_inode(struct fuse_conn *fc, u64 nodeid, > fi = get_fuse_inode(inode); > spin_lock(&fi->lock); > fi->attr_version = atomic64_inc_return(&fc->attr_version); > + fi->i_time = 0; > spin_unlock(&fi->lock); > > fuse_invalidate_attr(inode); > -- > 2.35.1 >