Re: [RFC PATCH] fuse: update attributes on read() only on timeout

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, Sep 30, 2020 at 6:36 AM Amir Goldstein <amir73il@gmail.com> wrote:

> I wonder out loud if this change of behavior you proposed is a good opportunity
> to introduce some of the verbs from SMB oplocks / NFS delegations into the
> FUSE protocol in order to allow finer grained control over per-file
> (and later also per-directory) caching behavior.

That would be really nice.  Let me find a recent discussion on this...
ah it was private.   Copying the thread below.  Thoughts?

Thanks,
Miklos

On Tue, Aug 11, 2020 at 8:56 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Wed, Aug 5, 2020 at 5:53 AM Zhi Zhang <zhang.david2011@gmail.com> wrote:
> > On Tue, Aug 4, 2020 at 11:36 AM Zhi Zhang <zhang.david2011@gmail.com> wrote:
> > > On Mon, Aug 3, 2020 at 6:37 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > >
> > > > On Thu, Jul 23, 2020 at 12:40 PM Zhi Zhang <zhang.david2011@gmail.com> wrote:
>
> > > > > We are using distributed filesystem ceph-fuse and we enabled writeback
> > > > > cache on fuse which improves the write performance, but the file's
> > > > > size attribute can't be updated on another client even if the users on
> > > > > this client only read this file.
> > > > >
> > > > > From my understanding, if the file is not opened in write mode and
> > > > > already writes its buffered data to userspace filesystem like
> > > > > ceph-fuse, then its state should be clean. The upper userspace and
> > > > > remote server should be responsible for the data and consistency. So
> > > > > at this moment fuse could trust the attributes from the server which
> > > > > has the most authoritative information about this file.
> > > > >
> > > > > Please let me know your thoughts, then I can work on this patch. Thanks.
> > > >
> > > > Hi,
> > > >
> > > > Something like this makes sense, but I think we should be adding an
> > > > explicit state (a lease to read/write the data) to the fuse inode.
> > > >
> > > > Opening for write would automatically acquire the WRITE lease,
> > > > similarly opening for read would acquire the READ lease.  Then we need
> > > > a new notification for revoking a lease (FUSE_NOTIFY_REVOKE).  And we
> > > > need a new request for re-acquiring a lease (FUSE_REACQUIRE).
> > > >
> > > > Does that make sense?
> > > >
> > > > Would you mind discussing this on the linux-fsdevel mailing lists?
> > > >
> > > > Thanks,
> > > > Miklos>
> > Hi Miklos,
> >
> > Thanks for the comments. I thought about it but I still have a couple
> > of questions about the lease.
> >
> > 1. After acquiring a WRITE lease, when should we release(revoke) it?
> > Before I assumed the file would be clean once we wrote buffered data
> > to the userspace file system. Now if we introduce the lease, should we
> > release the WRITE lease once we write the buffered data or we need to
> > wait for the revoking notification from userspace file system?
>
> I think it's easier to wait for the notification, instead of trying to
> guess.   When the file is closed (released) then the lease is also
> implicitly released.
>
> > 2. What is the purpose of READ lease?
> > Once we hold the READ lease, we could trust cached attributes and data
> > until revoking notification from userspace file system?
>
> Yes.
>
> > 3. What is the purpose of re-acquiring a lease and why do we need a new request?
> > From my understanding, the lease mechanism is only known by kernel
> > fuse, not for libfuse.
>
> We don't necessarily need a new request, it could be implicit in the
> first uncached write.
>
> > To re-acquire a lease here is actually for READ
> > lease by sending a sync getattr request.
>
> Yes.
>
> Thanks,
> Miklos