All of lore.kernel.org
 help / color / mirror / Atom feed
From: JeffleXu <jefflexu@linux.alibaba.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: stefanha@redhat.com, miklos@szeredi.hu,
	linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com,
	bo.liu@linux.alibaba.com, joseph.qi@linux.alibaba.com
Subject: Re: [PATCH v6 0/7] fuse,virtiofs: support per-file DAX
Date: Wed, 20 Oct 2021 13:22:32 +0800	[thread overview]
Message-ID: <85e66fb6-7587-4b8b-3e6f-0fc1019996fc@linux.alibaba.com> (raw)
In-Reply-To: <YW2Q5Y3u1TMlQEcW@redhat.com>



On 10/18/21 11:21 PM, Vivek Goyal wrote:
> On Mon, Oct 11, 2021 at 11:00:45AM +0800, Jeffle Xu wrote:
>> changes since v5:
>> Overall Design Changes:
>> 1. virtiofsd now supports ioctl (only FS_IOC_SETFLAGS and
>>   FS_IOC_FSSETXATTR), so that users inside guest could set/clear
>>   persistent inode flags now. (FUSE kernel module has already supported
>>   .ioctl(), virtiofsd need to suuport it.)
> 
> So no changes needed in fuse side (kernel) to support FS_IOC_FSSETXATTR?
> Only virtiofsd needs to be changed. That sounds good.
> 

Yes, the fuse kernel modules has already supported FUSE_IOCTL.

Per inode DAX on ext4/xfs will also call d_mark_dontcache() and try to
evict this inode as soon as possible when the persistent (DAX) inode
attribute has changed, just like [1].

But because of following reason:
> 
>> 2. The
>>   algorithm used by virtiofsd to determine whether DAX shall be enabled
>>   or not is totally implementation specific, and thus the following
>>   scenario may exist: users inside guest has already set related persistent
>>   inode flag (i.e. FS_XFLAG_DAX) on corresponding file but FUSE server finnaly
>>   decides not to enable DAX for this file.

If we always call d_mark_dontcache() and try to evict this inode when
the persistent (DAX) inode attribute has changed, the DAX state returned
by virtiofsd may sustain the same, and thus the previous eviction is
totally wasted and unnecessary.

So, as the following said,

>> Also because of this, d_mark_dontcache() is
>>   not called when FS_IOC_SETFLAGS/FS_IOC_FSSETXATTR ioctl is done inside
>>   guest. It's delayed to be done if the FUSE_ATTR_DAX flag **indeed**
>>   changes (as showed in patch 6).

the call for d_mark_dontcache() and inode eviction is delayed when the
DAX state returned by virtiofsd **indeed** changed (when dentry is timed
out and a new FUSE_LOOKUP is requested). But the defect is that, if '-o
cache=always' is set for virtiofsd, then the DAX state won't be updated
for a long time, after users have changed the persistent (DAX) inode
attribute inside guest via FS_IOC_FSSETXATTR ioctl.



[1] https://www.spinics.net/lists/linux-fsdevel/msg200851.html

-- 
Thanks,
Jeffle

WARNING: multiple messages have this Message-ID (diff)
From: JeffleXu <jefflexu@linux.alibaba.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: miklos@szeredi.hu, virtio-fs@redhat.com,
	joseph.qi@linux.alibaba.com, linux-fsdevel@vger.kernel.org
Subject: Re: [Virtio-fs] [PATCH v6 0/7] fuse,virtiofs: support per-file DAX
Date: Wed, 20 Oct 2021 13:22:32 +0800	[thread overview]
Message-ID: <85e66fb6-7587-4b8b-3e6f-0fc1019996fc@linux.alibaba.com> (raw)
In-Reply-To: <YW2Q5Y3u1TMlQEcW@redhat.com>



On 10/18/21 11:21 PM, Vivek Goyal wrote:
> On Mon, Oct 11, 2021 at 11:00:45AM +0800, Jeffle Xu wrote:
>> changes since v5:
>> Overall Design Changes:
>> 1. virtiofsd now supports ioctl (only FS_IOC_SETFLAGS and
>>   FS_IOC_FSSETXATTR), so that users inside guest could set/clear
>>   persistent inode flags now. (FUSE kernel module has already supported
>>   .ioctl(), virtiofsd need to suuport it.)
> 
> So no changes needed in fuse side (kernel) to support FS_IOC_FSSETXATTR?
> Only virtiofsd needs to be changed. That sounds good.
> 

Yes, the fuse kernel modules has already supported FUSE_IOCTL.

Per inode DAX on ext4/xfs will also call d_mark_dontcache() and try to
evict this inode as soon as possible when the persistent (DAX) inode
attribute has changed, just like [1].

But because of following reason:
> 
>> 2. The
>>   algorithm used by virtiofsd to determine whether DAX shall be enabled
>>   or not is totally implementation specific, and thus the following
>>   scenario may exist: users inside guest has already set related persistent
>>   inode flag (i.e. FS_XFLAG_DAX) on corresponding file but FUSE server finnaly
>>   decides not to enable DAX for this file.

If we always call d_mark_dontcache() and try to evict this inode when
the persistent (DAX) inode attribute has changed, the DAX state returned
by virtiofsd may sustain the same, and thus the previous eviction is
totally wasted and unnecessary.

So, as the following said,

>> Also because of this, d_mark_dontcache() is
>>   not called when FS_IOC_SETFLAGS/FS_IOC_FSSETXATTR ioctl is done inside
>>   guest. It's delayed to be done if the FUSE_ATTR_DAX flag **indeed**
>>   changes (as showed in patch 6).

the call for d_mark_dontcache() and inode eviction is delayed when the
DAX state returned by virtiofsd **indeed** changed (when dentry is timed
out and a new FUSE_LOOKUP is requested). But the defect is that, if '-o
cache=always' is set for virtiofsd, then the DAX state won't be updated
for a long time, after users have changed the persistent (DAX) inode
attribute inside guest via FS_IOC_FSSETXATTR ioctl.



[1] https://www.spinics.net/lists/linux-fsdevel/msg200851.html

-- 
Thanks,
Jeffle


  reply	other threads:[~2021-10-20  5:22 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11  3:00 [PATCH v6 0/7] fuse,virtiofs: support per-file DAX Jeffle Xu
2021-10-11  3:00 ` [Virtio-fs] " Jeffle Xu
2021-10-11  3:00 ` [PATCH v6 1/7] fuse: add fuse_should_enable_dax() helper Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-11  3:00 ` [PATCH v6 2/7] fuse: make DAX mount option a tri-state Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-18 14:10   ` Vivek Goyal
2021-10-18 14:10     ` [Virtio-fs] " Vivek Goyal
2021-10-20  2:52     ` JeffleXu
2021-10-20  2:52       ` [Virtio-fs] " JeffleXu
2021-10-20 14:48       ` Vivek Goyal
2021-10-20 14:48         ` [Virtio-fs] " Vivek Goyal
2021-10-29  8:33         ` JeffleXu
2021-10-29  8:33           ` [Virtio-fs] " JeffleXu
2021-10-29 13:03           ` Vivek Goyal
2021-10-29 13:03             ` [Virtio-fs] " Vivek Goyal
2021-11-01  8:21             ` JeffleXu
2021-11-01  8:21               ` [Virtio-fs] " JeffleXu
2021-10-20 15:17       ` Vivek Goyal
2021-10-20 15:17         ` [Virtio-fs] " Vivek Goyal
2021-10-22  6:54         ` JeffleXu
2021-10-22  6:54           ` [Virtio-fs] " JeffleXu
2021-10-25 17:52           ` Ira Weiny
2021-10-25 17:52             ` [Virtio-fs] " Ira Weiny
2021-10-25 18:12             ` Vivek Goyal
2021-10-25 18:12               ` [Virtio-fs] " Vivek Goyal
2021-10-25 19:02               ` Ira Weiny
2021-10-25 19:02                 ` [Virtio-fs] " Ira Weiny
2021-10-25 19:33                 ` Vivek Goyal
2021-10-25 19:33                   ` [Virtio-fs] " Vivek Goyal
2021-10-25 20:41                   ` Ira Weiny
2021-10-25 20:41                     ` [Virtio-fs] " Ira Weiny
2021-10-26 13:45                     ` Vivek Goyal
2021-10-26 13:45                       ` [Virtio-fs] " Vivek Goyal
2021-10-27  6:00                 ` JeffleXu
2021-10-27  6:00                   ` [Virtio-fs] " JeffleXu
2021-10-11  3:00 ` [PATCH v6 3/7] fuse: support per-file DAX in fuse protocol Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-18 14:14   ` Vivek Goyal
2021-10-18 14:14     ` [Virtio-fs] " Vivek Goyal
2021-10-18 14:20     ` Vivek Goyal
2021-10-18 14:20       ` [Virtio-fs] " Vivek Goyal
2021-10-20  3:04       ` JeffleXu
2021-10-20  3:04         ` [Virtio-fs] " JeffleXu
2021-10-20 14:54         ` Vivek Goyal
2021-10-20 14:54           ` [Virtio-fs] " Vivek Goyal
2021-10-11  3:00 ` [PATCH v6 4/7] fuse: negotiate per-file DAX in FUSE_INIT Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-18 14:30   ` Vivek Goyal
2021-10-18 14:30     ` [Virtio-fs] " Vivek Goyal
2021-10-20  3:10     ` JeffleXu
2021-10-20  3:10       ` [Virtio-fs] " JeffleXu
2021-10-20 15:44       ` Vivek Goyal
2021-10-20 15:44         ` [Virtio-fs] " Vivek Goyal
2021-10-11  3:00 ` [PATCH v6 5/7] fuse: enable per-file DAX Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-18 15:11   ` Vivek Goyal
2021-10-18 15:11     ` [Virtio-fs] " Vivek Goyal
2021-10-11  3:00 ` [PATCH v6 6/7] fuse: mark inode DONT_CACHE when per-file DAX hint changes Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-18 15:19   ` Vivek Goyal
2021-10-18 15:19     ` [Virtio-fs] " Vivek Goyal
2021-10-27  5:05     ` JeffleXu
2021-10-27  5:05       ` [Virtio-fs] " JeffleXu
2021-10-11  3:00 ` [PATCH v6 7/7] Documentation/filesystem/dax: record DAX on virtiofs Jeffle Xu
2021-10-11  3:00   ` [Virtio-fs] " Jeffle Xu
2021-10-15  3:33 ` [PATCH v6 0/7] fuse,virtiofs: support per-file DAX JeffleXu
2021-10-15  3:33   ` [Virtio-fs] " JeffleXu
2021-10-18 15:21 ` Vivek Goyal
2021-10-18 15:21   ` [Virtio-fs] " Vivek Goyal
2021-10-20  5:22   ` JeffleXu [this message]
2021-10-20  5:22     ` JeffleXu
2021-10-20 16:06     ` Vivek Goyal
2021-10-20 16:06       ` [Virtio-fs] " 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=85e66fb6-7587-4b8b-3e6f-0fc1019996fc@linux.alibaba.com \
    --to=jefflexu@linux.alibaba.com \
    --cc=bo.liu@linux.alibaba.com \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --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.