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 A842EC43334 for ; Thu, 23 Jun 2022 19:25:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230326AbiFWTZg (ORCPT ); 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 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 >