From: Jeff Layton <jlayton@kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] fuse: require FUSE drivers to opt-in for local file leases
Date: Tue, 26 Mar 2024 06:10:45 -0400 [thread overview]
Message-ID: <c1ba341a7f6b7bd631be7f2a992910acd2c497da.camel@kernel.org> (raw)
In-Reply-To: <CAJfpegvTOe8GpsdRUcvi6Ctb7SnBQHrbfP9Kr3Xc4PU5ac0jCw@mail.gmail.com>
On Tue, 2024-03-26 at 10:47 +0100, Miklos Szeredi wrote:
> On Tue, 19 Mar 2024 at 17:54, Jeff Layton <jlayton@kernel.org> wrote:
> >
> > Traditionally, we've allowed people to set leases on FUSE inodes. Some
> > FUSE drivers are effectively local filesystems and should be fine with
> > kernel-internal lease support. But others are backed by a network server
> > that may have multiple clients, or may be backed by something non-file
> > like entirely.
> >
> > Have the filesytem driver to set a fuse_conn flag to indicate whether it
> > wants support for local, in-kernel leases. If the flag is unset (the
> > default), then setlease attempts will fail with -EINVAL, indicating that
> > leases aren't supported on that inode.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > This is only tested for compilation, but it's fairly straightforward.
> > Having the FUSE drivers opt-out of this support might be more
> > backward-compatible, but that is a bit more dangerous. I'd rather driver
> > maintainer consciously opt-in.
>
> In the end the lease behavior will need to be reverted if there are
> regressions. I really don't know which is worse, the risk of
> regressions or the of risk data corruption...
>
Yeah, it's a tough call. My hope was that FUSE drivers that did want
lease support can just set the flag and and rebuild. Worst case, they'd
just lose lease support until that was done. Lease support is generally
an optimization, so things should still work but may be slower.
> Also I'd prefer a more general flag indicating that the the kernel
> driver can assume no external changes to the filesystem. E.g.
> FUSE_NO_OUTSIDE_CHANGE.
>
> Does this make sense? Can you imagine a case where FUSE_LOCAL_LEASES
> would be set, but caching policy would not assume no external changes?
>
No, that seems like it would work just as well. I can respin the patch
along those lines and resend.
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2024-03-26 10:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 16:54 [PATCH RFC] fuse: require FUSE drivers to opt-in for local file leases Jeff Layton
2024-03-26 9:47 ` Miklos Szeredi
2024-03-26 10:10 ` Jeff Layton [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=c1ba341a7f6b7bd631be7f2a992910acd2c497da.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 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).