From: Vivek Goyal <vgoyal@redhat.com>
To: linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com, miklos@szeredi.hu
Subject: Re: [Virtio-fs] [RFC PATCH 0/2] fuse: Enable SB_NOSEC if filesystem is not shared
Date: Tue, 1 Sep 2020 16:46:37 -0400 [thread overview]
Message-ID: <20200901204637.GA1232696@redhat.com> (raw)
In-Reply-To: <20200901204045.1250822-1-vgoyal@redhat.com>
On Tue, Sep 01, 2020 at 04:40:43PM -0400, Vivek Goyal wrote:
> Hi,
>
> I want to enable SB_NOSEC in fuse in some form so that performance of
> small random writes can be improved. As of now, we call file_remove_privs(),
> which results in fuse always sending getxattr(security.capability) to
> server to figure out if security.capability has been set on file or not.
> If it has been set, it needs to be cleared. This slows down small
> random writes tremendously.
>
> I posted couple of proposals in the past here.
>
> Proposal 1:
>
> https://lore.kernel.org/linux-fsdevel/20200716144032.GC422759@redhat.com/
>
> Proposal 2:
>
> https://lore.kernel.org/linux-fsdevel/20200724183812.19573-1-vgoyal@redhat.com/
>
> This is 3rd proposal now. One of the roadblocks in enabling SB_NOSEC
> is shared filesystem. It is possible that another client modified the
> file data and this client does not know about it. So we might regress
> if we don't fetch security.capability always.
>
> So looks like this needs to be handled different for shared filesystems
> and non-shared filesystems. non-shared filesystems will be more like
> local filesystems where fuse does not expect file data/metadata to
> change outside the fuse. And we should be able to enable SB_NOSEC
> optimization. This is what this proposal does.
>
> It does not handle the case of shared filesystems. I believe solution
> to that will depend on filesystem based on what's the cache coherency
> guarantees filesystem provides and what's the cache invalidation
> mechanism it uses.
>
> For now, all filesystems which are not shared can benefit from this
> optimization. I am interested in virtiofs which is not shared in
> many of the cases. In fact we don't even support shared mode yet.
Here is the corresponding qemu virtiofsd patch which can enable this
feature.
Subject: virtiofsd: Enable FUSE_NONSHARED_FS by default
Set FUSE_NONSHARED_FS flag by default as we don't support sharing of
virtiofs filesystem yet. Once that is supported, it should not be set
for shared mode.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
include/standard-headers/linux/fuse.h | 4 ++++
tools/virtiofsd/fuse_lowlevel.c | 9 +++++++++
2 files changed, 13 insertions(+)
Index: qemu/include/standard-headers/linux/fuse.h
===================================================================
--- qemu.orig/include/standard-headers/linux/fuse.h 2020-09-01 15:22:31.449707002 -0400
+++ qemu/include/standard-headers/linux/fuse.h 2020-09-01 15:23:18.776668542 -0400
@@ -172,6 +172,8 @@
* - add FUSE_WRITE_KILL_PRIV flag
* - add FUSE_SETUPMAPPING and FUSE_REMOVEMAPPING
* - add map_alignment to fuse_init_out, add FUSE_MAP_ALIGNMENT flag
+ * 7.32
+ * - add FUSE_NONSHARED_FS flag
*/
#ifndef _LINUX_FUSE_H
@@ -310,6 +312,7 @@ struct fuse_file_lock {
* FUSE_NO_OPENDIR_SUPPORT: kernel supports zero-message opendir
* FUSE_EXPLICIT_INVAL_DATA: only invalidate cached pages on explicit request
* FUSE_MAP_ALIGNMENT: map_alignment field is valid
+ * FUSE_NONSHARED_FS: Filesystem is not shared.
*/
#define FUSE_ASYNC_READ (1 << 0)
#define FUSE_POSIX_LOCKS (1 << 1)
@@ -338,6 +341,7 @@ struct fuse_file_lock {
#define FUSE_NO_OPENDIR_SUPPORT (1 << 24)
#define FUSE_EXPLICIT_INVAL_DATA (1 << 25)
#define FUSE_MAP_ALIGNMENT (1 << 26)
+#define FUSE_NONSHARED_FS (1 << 27)
/**
* CUSE INIT request/reply flags
Index: qemu/tools/virtiofsd/fuse_lowlevel.c
===================================================================
--- qemu.orig/tools/virtiofsd/fuse_lowlevel.c 2020-09-01 15:22:31.449707002 -0400
+++ qemu/tools/virtiofsd/fuse_lowlevel.c 2020-09-01 15:23:18.777668583 -0400
@@ -2218,6 +2218,15 @@ static void do_init(fuse_req_t req, fuse
outarg.map_alignment = ffsl(sysconf(_SC_PAGE_SIZE)) - 1;
}
+ if (arg->flags & FUSE_NONSHARED_FS) {
+ /*
+ * By default virtiofs is not shared. Once we support sharing,
+ * this will be have to a conditional and driven by user's
+ * selection.
+ */
+ outarg.flags |= FUSE_NONSHARED_FS;
+ }
+
fuse_log(FUSE_LOG_DEBUG, " INIT: %u.%u\n", outarg.major, outarg.minor);
fuse_log(FUSE_LOG_DEBUG, " flags=0x%08x\n", outarg.flags);
fuse_log(FUSE_LOG_DEBUG, " max_readahead=0x%08x\n", outarg.max_readahead);
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com, miklos@szeredi.hu
Cc: stefanha@redhat.com, dgilbert@redhat.com
Subject: Re: [RFC PATCH 0/2] fuse: Enable SB_NOSEC if filesystem is not shared
Date: Tue, 1 Sep 2020 16:46:37 -0400 [thread overview]
Message-ID: <20200901204637.GA1232696@redhat.com> (raw)
In-Reply-To: <20200901204045.1250822-1-vgoyal@redhat.com>
On Tue, Sep 01, 2020 at 04:40:43PM -0400, Vivek Goyal wrote:
> Hi,
>
> I want to enable SB_NOSEC in fuse in some form so that performance of
> small random writes can be improved. As of now, we call file_remove_privs(),
> which results in fuse always sending getxattr(security.capability) to
> server to figure out if security.capability has been set on file or not.
> If it has been set, it needs to be cleared. This slows down small
> random writes tremendously.
>
> I posted couple of proposals in the past here.
>
> Proposal 1:
>
> https://lore.kernel.org/linux-fsdevel/20200716144032.GC422759@redhat.com/
>
> Proposal 2:
>
> https://lore.kernel.org/linux-fsdevel/20200724183812.19573-1-vgoyal@redhat.com/
>
> This is 3rd proposal now. One of the roadblocks in enabling SB_NOSEC
> is shared filesystem. It is possible that another client modified the
> file data and this client does not know about it. So we might regress
> if we don't fetch security.capability always.
>
> So looks like this needs to be handled different for shared filesystems
> and non-shared filesystems. non-shared filesystems will be more like
> local filesystems where fuse does not expect file data/metadata to
> change outside the fuse. And we should be able to enable SB_NOSEC
> optimization. This is what this proposal does.
>
> It does not handle the case of shared filesystems. I believe solution
> to that will depend on filesystem based on what's the cache coherency
> guarantees filesystem provides and what's the cache invalidation
> mechanism it uses.
>
> For now, all filesystems which are not shared can benefit from this
> optimization. I am interested in virtiofs which is not shared in
> many of the cases. In fact we don't even support shared mode yet.
Here is the corresponding qemu virtiofsd patch which can enable this
feature.
Subject: virtiofsd: Enable FUSE_NONSHARED_FS by default
Set FUSE_NONSHARED_FS flag by default as we don't support sharing of
virtiofs filesystem yet. Once that is supported, it should not be set
for shared mode.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
include/standard-headers/linux/fuse.h | 4 ++++
tools/virtiofsd/fuse_lowlevel.c | 9 +++++++++
2 files changed, 13 insertions(+)
Index: qemu/include/standard-headers/linux/fuse.h
===================================================================
--- qemu.orig/include/standard-headers/linux/fuse.h 2020-09-01 15:22:31.449707002 -0400
+++ qemu/include/standard-headers/linux/fuse.h 2020-09-01 15:23:18.776668542 -0400
@@ -172,6 +172,8 @@
* - add FUSE_WRITE_KILL_PRIV flag
* - add FUSE_SETUPMAPPING and FUSE_REMOVEMAPPING
* - add map_alignment to fuse_init_out, add FUSE_MAP_ALIGNMENT flag
+ * 7.32
+ * - add FUSE_NONSHARED_FS flag
*/
#ifndef _LINUX_FUSE_H
@@ -310,6 +312,7 @@ struct fuse_file_lock {
* FUSE_NO_OPENDIR_SUPPORT: kernel supports zero-message opendir
* FUSE_EXPLICIT_INVAL_DATA: only invalidate cached pages on explicit request
* FUSE_MAP_ALIGNMENT: map_alignment field is valid
+ * FUSE_NONSHARED_FS: Filesystem is not shared.
*/
#define FUSE_ASYNC_READ (1 << 0)
#define FUSE_POSIX_LOCKS (1 << 1)
@@ -338,6 +341,7 @@ struct fuse_file_lock {
#define FUSE_NO_OPENDIR_SUPPORT (1 << 24)
#define FUSE_EXPLICIT_INVAL_DATA (1 << 25)
#define FUSE_MAP_ALIGNMENT (1 << 26)
+#define FUSE_NONSHARED_FS (1 << 27)
/**
* CUSE INIT request/reply flags
Index: qemu/tools/virtiofsd/fuse_lowlevel.c
===================================================================
--- qemu.orig/tools/virtiofsd/fuse_lowlevel.c 2020-09-01 15:22:31.449707002 -0400
+++ qemu/tools/virtiofsd/fuse_lowlevel.c 2020-09-01 15:23:18.777668583 -0400
@@ -2218,6 +2218,15 @@ static void do_init(fuse_req_t req, fuse
outarg.map_alignment = ffsl(sysconf(_SC_PAGE_SIZE)) - 1;
}
+ if (arg->flags & FUSE_NONSHARED_FS) {
+ /*
+ * By default virtiofs is not shared. Once we support sharing,
+ * this will be have to a conditional and driven by user's
+ * selection.
+ */
+ outarg.flags |= FUSE_NONSHARED_FS;
+ }
+
fuse_log(FUSE_LOG_DEBUG, " INIT: %u.%u\n", outarg.major, outarg.minor);
fuse_log(FUSE_LOG_DEBUG, " flags=0x%08x\n", outarg.flags);
fuse_log(FUSE_LOG_DEBUG, " max_readahead=0x%08x\n", outarg.max_readahead);
next prev parent reply other threads:[~2020-09-01 20:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 20:40 [Virtio-fs] [RFC PATCH 0/2] fuse: Enable SB_NOSEC if filesystem is not shared Vivek Goyal
2020-09-01 20:40 ` Vivek Goyal
2020-09-01 20:40 ` [Virtio-fs] [PATCH 1/2] fuse: Add a flag FUSE_NONSHARED_FS Vivek Goyal
2020-09-01 20:40 ` Vivek Goyal
2020-09-02 6:57 ` [Virtio-fs] " Miklos Szeredi
2020-09-02 6:57 ` Miklos Szeredi
2020-09-02 18:08 ` [Virtio-fs] " Vivek Goyal
2020-09-02 18:08 ` Vivek Goyal
2020-09-01 20:40 ` [Virtio-fs] [PATCH 2/2] fuse: Enable SB_NOSEC if filesystem is not shared Vivek Goyal
2020-09-01 20:40 ` Vivek Goyal
2020-09-01 20:46 ` Vivek Goyal [this message]
2020-09-01 20:46 ` [RFC PATCH 0/2] " Vivek Goyal
2020-09-02 19:14 ` [Virtio-fs] " Vivek Goyal
2020-09-02 19:14 ` 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=20200901204637.GA1232696@redhat.com \
--to=vgoyal@redhat.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.