Thankx a ton Framk. It was very useful.
I had few more questions...
>
> 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.
>
1> If this is the case then is there any reason other than multiple
protocol support(NFSv4,CIFS), for underlying Filesystem to implement
locks?? Assuming there cant be multiple active nfs-ganesha
heads for the same FS object...
>
> 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.
>
> 2> If the identity of the owner is valid for only single ganesha head
without it being restarted why does underlying Filesystem need to keep this
owner??
Will it receive locking requests if nfs-ganesha detects a conflict??
thankx
kanishk
> 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
>
>
--
regards
kanishk
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
