From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, virtio-fs-list <virtio-fs@redhat.com>
Subject: Re: [Virtio-fs] [PATCH 1/2] fuse: Add a flag FUSE_NONSHARED_FS
Date: Wed, 2 Sep 2020 14:08:04 -0400 [thread overview]
Message-ID: <20200902180804.GB1263242@redhat.com> (raw)
In-Reply-To: <CAJfpegtUMJqUDhFTePpFP=oQ=XGFj2tfvx+unV94sN3fFZbZHg@mail.gmail.com>
On Wed, Sep 02, 2020 at 08:57:07AM +0200, Miklos Szeredi wrote:
> On Tue, Sep 1, 2020 at 10:41 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > FUSE_NONSHARED_FS will signify that filesystem is not shared. That is
> > all fuse modifications are going thourgh this single fuse connection. It
> > should not happen that file's data/metadata changed without the knowledge
> > of fuse. Automatic file time stamp changes will probably be an exception
> > to this rule.
> >
> > If filesystem is shared between different clients, then this flag should
> > not be set.
>
> I'm thinking maybe this flag should force some other parameters as well:
So you are thinking of fuse enforcing these parameters automatically
without server asking for it. IOW, override what server says about
following parameters and fuse sets their values if
FUSE_NONSHARED_FS is set?
Or should we recommend these for FUSE_NONSHARED_FS and let file server
specify all this.
>
> ^FUSE_POSIX_LOCK
No remote posix locks. Makes sense. If filesystem is not shared then
there is no need of remote posix locks.
> ^FUSE_FLOCK_LOCKS
No remote BSD style file locks. If filesystem is not shared, then
local locks should work just fine.
> ^FUSE_AUTO_INVAL_DATA
This controls if page cache data should be invalidated upon mtime
change. For non shared fs, mtime should not change outside fuse,
so makes sense to enforce ^FUSE_AUTO_INVAL_DATA.
> FUSE_EXPLICIT_INVAL_DATA
This tells fuse to not invalidate page cache and not truncate page cache
if attr->size or mtime change is detected. For non-shared fs we don't
expect attr->size or mtime to change, so it does not harm to enfroce
this.
> FUSE_CACHE_SYMLINKS
This caches readlink responses. Makes sense to enable it for
non shared fs.
> attr_valid=inf
> entry_valid=inf
dentry and attr timeout being infinite should be good for performance
if filesystem is not shared.
> FOPEN_KEEP_CACHE
If this is not set, by default fuse invalidates page cache on open. Makes
sense to not flush page cache on open with FUSE_NONSHARED_FS.
> FOPEN_CACHE_DIR
Caching directory contents for FUSE_NONSHARED_FS makes sense too.
>
> This would make sure that it's really only used in the non-shared case.
I am little afraid of enforcing this in fuse core because tomorrow
somebody will say hey I need hybrid mode where FUSE_NONSHARED_FS is
set but for some reason I want attrs to expire after some time. I
don't have a good use case in my mind though.
If I were to choose, I will probably document it and suggest that
file servers sets all the above for the case of FUSE_NONSHARED_FS.
But I am also open to enforcing this in fuse core if you prefer
that option.
Thanks
Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org,
virtio-fs-list <virtio-fs@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 1/2] fuse: Add a flag FUSE_NONSHARED_FS
Date: Wed, 2 Sep 2020 14:08:04 -0400 [thread overview]
Message-ID: <20200902180804.GB1263242@redhat.com> (raw)
In-Reply-To: <CAJfpegtUMJqUDhFTePpFP=oQ=XGFj2tfvx+unV94sN3fFZbZHg@mail.gmail.com>
On Wed, Sep 02, 2020 at 08:57:07AM +0200, Miklos Szeredi wrote:
> On Tue, Sep 1, 2020 at 10:41 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > FUSE_NONSHARED_FS will signify that filesystem is not shared. That is
> > all fuse modifications are going thourgh this single fuse connection. It
> > should not happen that file's data/metadata changed without the knowledge
> > of fuse. Automatic file time stamp changes will probably be an exception
> > to this rule.
> >
> > If filesystem is shared between different clients, then this flag should
> > not be set.
>
> I'm thinking maybe this flag should force some other parameters as well:
So you are thinking of fuse enforcing these parameters automatically
without server asking for it. IOW, override what server says about
following parameters and fuse sets their values if
FUSE_NONSHARED_FS is set?
Or should we recommend these for FUSE_NONSHARED_FS and let file server
specify all this.
>
> ^FUSE_POSIX_LOCK
No remote posix locks. Makes sense. If filesystem is not shared then
there is no need of remote posix locks.
> ^FUSE_FLOCK_LOCKS
No remote BSD style file locks. If filesystem is not shared, then
local locks should work just fine.
> ^FUSE_AUTO_INVAL_DATA
This controls if page cache data should be invalidated upon mtime
change. For non shared fs, mtime should not change outside fuse,
so makes sense to enforce ^FUSE_AUTO_INVAL_DATA.
> FUSE_EXPLICIT_INVAL_DATA
This tells fuse to not invalidate page cache and not truncate page cache
if attr->size or mtime change is detected. For non-shared fs we don't
expect attr->size or mtime to change, so it does not harm to enfroce
this.
> FUSE_CACHE_SYMLINKS
This caches readlink responses. Makes sense to enable it for
non shared fs.
> attr_valid=inf
> entry_valid=inf
dentry and attr timeout being infinite should be good for performance
if filesystem is not shared.
> FOPEN_KEEP_CACHE
If this is not set, by default fuse invalidates page cache on open. Makes
sense to not flush page cache on open with FUSE_NONSHARED_FS.
> FOPEN_CACHE_DIR
Caching directory contents for FUSE_NONSHARED_FS makes sense too.
>
> This would make sure that it's really only used in the non-shared case.
I am little afraid of enforcing this in fuse core because tomorrow
somebody will say hey I need hybrid mode where FUSE_NONSHARED_FS is
set but for some reason I want attrs to expire after some time. I
don't have a good use case in my mind though.
If I were to choose, I will probably document it and suggest that
file servers sets all the above for the case of FUSE_NONSHARED_FS.
But I am also open to enforcing this in fuse core if you prefer
that option.
Thanks
Vivek
next prev parent reply other threads:[~2020-09-02 18:08 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 ` Vivek Goyal [this message]
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 ` [Virtio-fs] [RFC PATCH 0/2] " Vivek Goyal
2020-09-01 20:46 ` 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=20200902180804.GB1263242@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.