On Wed, Sep 30, 2020 at 6:36 AM Amir Goldstein <amir73il@xxxxxxxxx> 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@xxxxxxxxxx> wrote: > > On Wed, Aug 5, 2020 at 5:53 AM Zhi Zhang <zhang.david2011@xxxxxxxxx> wrote: > > On Tue, Aug 4, 2020 at 11:36 AM Zhi Zhang <zhang.david2011@xxxxxxxxx> wrote: > > > On Mon, Aug 3, 2020 at 6:37 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Jul 23, 2020 at 12:40 PM Zhi Zhang <zhang.david2011@xxxxxxxxx> 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
