Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com, miklos@szeredi.hu
Cc: vgoyal@redhat.com, stefanha@redhat.com, dgilbert@redhat.com
Subject: [RFC PATCH 0/2] fuse: Enable SB_NOSEC if filesystem is not shared
Date: Tue,  1 Sep 2020 16:40:43 -0400	[thread overview]
Message-ID: <20200901204045.1250822-1-vgoyal@redhat.com> (raw)

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. 

Any comments or feedback is welcome.

Thanks
Vivek

Vivek Goyal (2):
  fuse: Add a flag FUSE_NONSHARED_FS
  fuse: Enable SB_NOSEC if filesystem is not shared

 fs/fuse/fuse_i.h          |  3 +++
 fs/fuse/inode.c           | 12 +++++++++++-
 include/uapi/linux/fuse.h |  4 ++++
 3 files changed, 18 insertions(+), 1 deletion(-)

-- 
2.25.4


             reply	other threads:[~2020-09-01 20:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 20:40 Vivek Goyal [this message]
2020-09-01 20:40 ` [PATCH 1/2] fuse: Add a flag FUSE_NONSHARED_FS Vivek Goyal
2020-09-02  6:57   ` Miklos Szeredi
2020-09-02 18:08     ` Vivek Goyal
2020-09-01 20:40 ` [PATCH 2/2] fuse: Enable SB_NOSEC if filesystem is not shared Vivek Goyal
2020-09-01 20:46 ` [RFC PATCH 0/2] " 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=20200901204045.1250822-1-vgoyal@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=stefanha@redhat.com \
    --cc=virtio-fs@redhat.com \
    --subject='Re: [RFC PATCH 0/2] fuse: Enable SB_NOSEC if filesystem is not shared' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).