> -----Original Message----- > From: Soumya Koduri [mailto:skod...@redhat.com] > Sent: Tuesday, July 26, 2016 10:00 AM > To: Frank Filz <ffilz...@mindspring.com>; 'kanishk rastogi' > <kanishk...@gmail.com>; nfs-ganesha-devel@lists.sourceforge.net > Subject: Re: [Nfs-ganesha-devel] FSAL locks implementation > > Thanks for your inputs Frank. > > On 07/26/2016 09:46 PM, Frank Filz wrote: > > 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. > > But what about the case where Ganesha process doesn't crash but still there > could be failover/failback happening between two active ganesha > servers(for eg., load-balancing). We ensure nfs-ganesha servers going to > grace period using dbus commands. But then even though the clients try to > reclaim their locks using their previous lock owner, since the state_owner > struct is now changed, backend FS may assume it as a new lock request and > may deny it as there is still old lock present with a different owner. Or does > NFS-Ganesha duly unlocks all its existing locks whenever it enters grace- > period either after hard reboot or via dbus?
That is why we have the release_IP dBus command, it signals the Ganesha that is giving up clients to drop their locks. 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
