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: stefanha@redhat.com, dgilbert@redhat.com, eric.ernst@intel.com
Subject: Re: [RFC PATCH 0/2] fuse: Enable SB_NOSEC if filesystem is not shared
Date: Wed, 2 Sep 2020 15:14:17 -0400	[thread overview]
Message-ID: <20200902191417.GC1263242@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. 

Well, I was hoping that virtiofs and kata containers can directly
benefit from this mode for root filesystem image. But Eric Ernst
says that kata containers keep bunch of things in a single directory
being exported to guest. And while rootfs image is not expected to
be updated later, it is possile kubernetes updates other parts
later.

And that most likely means kata will not use virtiofs non-shared
mode. 

I guess I need to keep this idea on hold for now because I will not
have any immediate users. And go back to drawing board and figure out
how to not query security.capability on every WRITE.

Thanks
Vivek

> 
> 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
> 


      parent reply	other threads:[~2020-09-02 19:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 20:40 Vivek Goyal
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 [this message]

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=20200902191417.GC1263242@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.ernst@intel.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).