All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Jeffle Xu <jefflexu@linux.alibaba.com>
Cc: virtio-fs@redhat.com, linux-fsdevel@vger.kernel.org,
	joseph.qi@linux.alibaba.com, miklos@szeredi.hu
Subject: Re: [Virtio-fs] [PATCH v8 6/7] fuse: mark inode DONT_CACHE when per inode DAX hint changes
Date: Tue, 7 Dec 2021 11:00:34 -0500	[thread overview]
Message-ID: <Ya+FIsGgn4wsYG+4@redhat.com> (raw)
In-Reply-To: <20211125070530.79602-7-jefflexu@linux.alibaba.com>

On Thu, Nov 25, 2021 at 03:05:29PM +0800, Jeffle Xu wrote:
> When the per inode DAX hint changes while the file is still *opened*, it
> is quite complicated and maybe fragile to dynamically change the DAX
> state.
> 
> Hence mark the inode and corresponding dentries as DONE_CACHE once the
> per inode DAX hint changes, so that the inode instance will be evicted
> and freed as soon as possible once the file is closed and the last
> reference to the inode is put. And then when the file gets reopened next
> time, the new instantiated inode will reflect the new DAX state.
> 
> In summary, when the per inode DAX hint changes for an *opened* file, the
> DAX state of the file won't be updated until this file is closed and
> reopened later.

Is this true for cache=always mode as well? If inode continues to be
cached in guest cache, I am assuming we will not refresh inode attrs
due to cache=always mode and will not get new DAX state from server.

IOW, changing DAX state of file is combination of two things.

A. Client comes to know about it using GETATTR.
B. Once client knows about updated state, it will take affect when
   existing inode is released and new inode is instantiated.

And step A might take time depending on cache mode as well as when
is GETATTR actually initiated by the client. Its not deterministic
and can't be guaranteed. Right?

Vivek

> 
> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
> ---
>  fs/fuse/dax.c    | 9 +++++++++
>  fs/fuse/fuse_i.h | 1 +
>  fs/fuse/inode.c  | 3 +++
>  3 files changed, 13 insertions(+)
> 
> diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c
> index 234c2278420f..b19e7eaed4ef 100644
> --- a/fs/fuse/dax.c
> +++ b/fs/fuse/dax.c
> @@ -1363,6 +1363,15 @@ void fuse_dax_inode_init(struct inode *inode, unsigned int flags)
>  	inode->i_data.a_ops = &fuse_dax_file_aops;
>  }
>  
> +void fuse_dax_dontcache(struct inode *inode, unsigned int flags)
> +{
> +	struct fuse_conn *fc = get_fuse_conn(inode);
> +
> +	if (fuse_is_inode_dax_mode(fc->dax_mode) &&
> +	    (!!IS_DAX(inode) != !!(flags & FUSE_ATTR_DAX)))
> +		d_mark_dontcache(inode);
> +}
> +
>  bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int map_alignment)
>  {
>  	if (fc->dax && (map_alignment > FUSE_DAX_SHIFT)) {
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index 83970723314a..af19d1d821ea 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
> @@ -1293,6 +1293,7 @@ void fuse_dax_conn_free(struct fuse_conn *fc);
>  bool fuse_dax_inode_alloc(struct super_block *sb, struct fuse_inode *fi);
>  void fuse_dax_inode_init(struct inode *inode, unsigned int flags);
>  void fuse_dax_inode_cleanup(struct inode *inode);
> +void fuse_dax_dontcache(struct inode *inode, unsigned int flags);
>  bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int map_alignment);
>  void fuse_dax_cancel_work(struct fuse_conn *fc);
>  
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index b26612fce6d0..b25d99eb8411 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -301,6 +301,9 @@ void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr,
>  		if (inval)
>  			invalidate_inode_pages2(inode->i_mapping);
>  	}
> +
> +	if (IS_ENABLED(CONFIG_FUSE_DAX))
> +		fuse_dax_dontcache(inode, attr->flags);
>  }
>  
>  static void fuse_init_inode(struct inode *inode, struct fuse_attr *attr)
> -- 
> 2.27.0
> 


WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Jeffle Xu <jefflexu@linux.alibaba.com>
Cc: stefanha@redhat.com, miklos@szeredi.hu, virtio-fs@redhat.com,
	linux-fsdevel@vger.kernel.org, joseph.qi@linux.alibaba.com
Subject: Re: [PATCH v8 6/7] fuse: mark inode DONT_CACHE when per inode DAX hint changes
Date: Tue, 7 Dec 2021 11:00:34 -0500	[thread overview]
Message-ID: <Ya+FIsGgn4wsYG+4@redhat.com> (raw)
In-Reply-To: <20211125070530.79602-7-jefflexu@linux.alibaba.com>

On Thu, Nov 25, 2021 at 03:05:29PM +0800, Jeffle Xu wrote:
> When the per inode DAX hint changes while the file is still *opened*, it
> is quite complicated and maybe fragile to dynamically change the DAX
> state.
> 
> Hence mark the inode and corresponding dentries as DONE_CACHE once the
> per inode DAX hint changes, so that the inode instance will be evicted
> and freed as soon as possible once the file is closed and the last
> reference to the inode is put. And then when the file gets reopened next
> time, the new instantiated inode will reflect the new DAX state.
> 
> In summary, when the per inode DAX hint changes for an *opened* file, the
> DAX state of the file won't be updated until this file is closed and
> reopened later.

Is this true for cache=always mode as well? If inode continues to be
cached in guest cache, I am assuming we will not refresh inode attrs
due to cache=always mode and will not get new DAX state from server.

IOW, changing DAX state of file is combination of two things.

A. Client comes to know about it using GETATTR.
B. Once client knows about updated state, it will take affect when
   existing inode is released and new inode is instantiated.

And step A might take time depending on cache mode as well as when
is GETATTR actually initiated by the client. Its not deterministic
and can't be guaranteed. Right?

Vivek

> 
> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
> ---
>  fs/fuse/dax.c    | 9 +++++++++
>  fs/fuse/fuse_i.h | 1 +
>  fs/fuse/inode.c  | 3 +++
>  3 files changed, 13 insertions(+)
> 
> diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c
> index 234c2278420f..b19e7eaed4ef 100644
> --- a/fs/fuse/dax.c
> +++ b/fs/fuse/dax.c
> @@ -1363,6 +1363,15 @@ void fuse_dax_inode_init(struct inode *inode, unsigned int flags)
>  	inode->i_data.a_ops = &fuse_dax_file_aops;
>  }
>  
> +void fuse_dax_dontcache(struct inode *inode, unsigned int flags)
> +{
> +	struct fuse_conn *fc = get_fuse_conn(inode);
> +
> +	if (fuse_is_inode_dax_mode(fc->dax_mode) &&
> +	    (!!IS_DAX(inode) != !!(flags & FUSE_ATTR_DAX)))
> +		d_mark_dontcache(inode);
> +}
> +
>  bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int map_alignment)
>  {
>  	if (fc->dax && (map_alignment > FUSE_DAX_SHIFT)) {
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index 83970723314a..af19d1d821ea 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
> @@ -1293,6 +1293,7 @@ void fuse_dax_conn_free(struct fuse_conn *fc);
>  bool fuse_dax_inode_alloc(struct super_block *sb, struct fuse_inode *fi);
>  void fuse_dax_inode_init(struct inode *inode, unsigned int flags);
>  void fuse_dax_inode_cleanup(struct inode *inode);
> +void fuse_dax_dontcache(struct inode *inode, unsigned int flags);
>  bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int map_alignment);
>  void fuse_dax_cancel_work(struct fuse_conn *fc);
>  
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index b26612fce6d0..b25d99eb8411 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -301,6 +301,9 @@ void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr,
>  		if (inval)
>  			invalidate_inode_pages2(inode->i_mapping);
>  	}
> +
> +	if (IS_ENABLED(CONFIG_FUSE_DAX))
> +		fuse_dax_dontcache(inode, attr->flags);
>  }
>  
>  static void fuse_init_inode(struct inode *inode, struct fuse_attr *attr)
> -- 
> 2.27.0
> 


  reply	other threads:[~2021-12-07 16:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25  7:05 [Virtio-fs] [PATCH v8 0/7] fuse,virtiofs: support per-file DAX Jeffle Xu
2021-11-25  7:05 ` Jeffle Xu
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 1/7] fuse: add fuse_should_enable_dax() helper Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-13 18:08   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:08     ` Vivek Goyal
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 2/7] fuse: make DAX mount option a tri-state Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-13 18:09   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:09     ` Vivek Goyal
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 3/7] fuse: support per inode DAX in fuse protocol Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-13 18:09   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:09     ` Vivek Goyal
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 4/7] fuse: enable per inode DAX Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-13 18:10   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:10     ` Vivek Goyal
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 5/7] fuse: negotiate per inode DAX in FUSE_INIT Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-13 18:10   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:10     ` Vivek Goyal
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 6/7] fuse: mark inode DONT_CACHE when per inode DAX hint changes Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-07 16:00   ` Vivek Goyal [this message]
2021-12-07 16:00     ` Vivek Goyal
2021-12-08  1:36     ` [Virtio-fs] " JeffleXu
2021-12-08  1:36       ` JeffleXu
2021-12-13 18:10   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:10     ` Vivek Goyal
2021-11-25  7:05 ` [Virtio-fs] [PATCH v8 7/7] Documentation/filesystem/dax: DAX on virtiofs Jeffle Xu
2021-11-25  7:05   ` Jeffle Xu
2021-12-13 18:11   ` [Virtio-fs] " Vivek Goyal
2021-12-13 18:11     ` Vivek Goyal
2021-12-13 18:12 ` [Virtio-fs] [PATCH v8 0/7] fuse,virtiofs: support per-file DAX Vivek Goyal
2021-12-13 18:12   ` Vivek Goyal

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=Ya+FIsGgn4wsYG+4@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=virtio-fs@redhat.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.