All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fuse: add FOPEN_INVAL_ATTR
Date: Mon, 27 Jun 2022 11:06:34 -0400	[thread overview]
Message-ID: <YrnHeqckLknFleud@redhat.com> (raw)
In-Reply-To: <20220608104202.19461-1-zhangjiachen.jaycee@bytedance.com>

On Wed, Jun 08, 2022 at 06:42:02PM +0800, Jiachen Zhang wrote:
> So that the fuse daemon can ask kernel to invalidate the attr cache on file
> open.

Will be great if there was a proper context around this. Without any
explanation, how one is supposed to understand how this is useful.

By going through other email threads, looks like, with writeback
cache enabled, you want to invalidate attr cache and data cache
when file is opened next time. Right?

IOW, when file is closed, its changes will be flushed out. And when
file is reopened, server somehow is supposed to determine if file
has changed (on server by another client) and based on that determine
whether to invalidate attr and data cache on next open?

Even without that, on next open, it probably makes sense to being
invalidate attr cache. We have notion to invalidate data cache. So
it will be kind of odd that we can invalidate data but not attrs
on next open. Am I understanding it right?

Thanks
Vivek

> 
> Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
> ---
>  fs/fuse/file.c            | 4 ++++
>  include/uapi/linux/fuse.h | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index fdcec3aa7830..9609d13ec351 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -213,6 +213,10 @@ void fuse_finish_open(struct inode *inode, struct file *file)
>  		file_update_time(file);
>  		fuse_invalidate_attr_mask(inode, FUSE_STATX_MODSIZE);
>  	}
> +
> +	if (ff->open_flags & FOPEN_INVAL_ATTR)
> +		fuse_invalidate_attr(inode);
> +
>  	if ((file->f_mode & FMODE_WRITE) && fc->writeback_cache)
>  		fuse_link_write_file(file);
>  }
> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> index d6ccee961891..0b0b7d308ddb 100644
> --- a/include/uapi/linux/fuse.h
> +++ b/include/uapi/linux/fuse.h
> @@ -301,6 +301,7 @@ struct fuse_file_lock {
>   * FOPEN_CACHE_DIR: allow caching this directory
>   * FOPEN_STREAM: the file is stream-like (no file position at all)
>   * FOPEN_NOFLUSH: don't flush data cache on close (unless FUSE_WRITEBACK_CACHE)
> + * FOPEN_INVAL_ATTR: invalidate the attr cache on open
>   */
>  #define FOPEN_DIRECT_IO		(1 << 0)
>  #define FOPEN_KEEP_CACHE	(1 << 1)
> @@ -308,6 +309,7 @@ struct fuse_file_lock {
>  #define FOPEN_CACHE_DIR		(1 << 3)
>  #define FOPEN_STREAM		(1 << 4)
>  #define FOPEN_NOFLUSH		(1 << 5)
> +#define FOPEN_INVAL_ATTR	(1 << 6)
>  
>  /**
>   * INIT request/reply flags
> -- 
> 2.20.1
> 


  reply	other threads:[~2022-06-27 15:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 10:42 [PATCH] fuse: add FOPEN_INVAL_ATTR Jiachen Zhang
2022-06-27 15:06 ` Vivek Goyal [this message]
2022-06-28  5:14   ` Jiachen Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YrnHeqckLknFleud@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=zhangjiachen.jaycee@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.