> On 07/26/2016 08:24 PM, kanishk rastogi wrote: > > > > hi all, > > I was going though the FSAL apis and had questions regarding the lock > > APi's expectation from the underlying filesystem... > > > > 1> Is it expected that the underlying-Filesystem will release the lock > > after the lease time expires? > > If yes is this the lease time exported by underlying > > Filesystem's FSAL layer? > > AFAIU, underlying fielesystem need not know about lease time. NFS-Ganesh > should send unlock to the backend FS post lease expiry.
Yes, at the moment, the SAL layer of Ganesha manages leases for NFS v4 clients. If the underlying filesystem has a lease period, the FSAL would be responsible for maintaining the underlying lease. > > 2> How is the underlying FSAL interpret the owner?? > > Can i assume that is will be of certain size so that i can > > identify the owner?? > > I dont see anyway for FSAL to tell nfsganesha about the lock > > owner if there is a conflicting lock. Why does underlying Filesystem > > need to know about the lock owner then ?? > > FWIU, I think current lock owner implementation is not correct. We pass in > "state_owner_t " structure contents in binary format to the backend FSAL > which shall change with nfs-ganesha reboots. We should be instead sending > lock owners sent by NFS-clients along with the size. > > Underlying filesystem need to know about lock-owners if it needs to > distinguish between the lock requests sent by the same NFS-ganesha head, > which refer to different NFS clients. The current FSAL lock owner implementation is a void * (though the FSAL DOES have visibility to the actual lock owner information if it needed to use it). Anything more would only be needed if the underlying filesystem was prepared to allow Ganesha to recover locks after a Ganesha crash. This would actually be necessary for an absolutely correct FSAL_PROXY implementation, unfortunately the NFS v4 protocol has limited provision for a client to recover it's lost state. The implementations we have been making on clustered filesystems have been to failover to another node and notify NFS v3 clients of a crash, and allow NFS v4 clients to discover the crash, and thus the clients reclaim the locks. Ideally, Ganesha as a cluster is able to enforce grace period. So with all of that, there's no real need for anything more than a void * pointer to the SAL state owner structure which provides the uniqueness of the owner for the duration of it's validity within the system. If Ganesha crashes, the underlying filesystem should dump state. If the protocol layer invalidates the owner (lease expiry or whatever), then all state will have been released and the owner no longer has meaning to the underlying filesystem. As far as conflicting locks, the FSAL can return a conflicting lock in the conflicting_lock parameter. Note that FSAL_VFS fetches this by making a F_GETLK call (which happens to be racy and the code doesn't actually handle the situation very well if the lock is now available!). I'm actually curious if any application (other than Ganesha...) actually tries to make any use of the returned conflicting lock with F_GETLK. It really isn't reliable for much of anything. Note that if Ganesha detects a conflict with a lock held by that Ganesha instance, it can return a more interesting lock owner to the client than if it has to get the conflicting lock from the FSAL. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
