From: kanishk rastogi [mailto:[email protected]]
Sent: Tuesday, July 26, 2016 10:22 PM
To: Frank Filz <[email protected]>
Cc: Soumya Koduri <[email protected]>; [email protected]
Subject: Re: [Nfs-ganesha-devel] FSAL locks implementation
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...
If the only access to the files is via Ganesha, and the filesystem is not
clustered, then no, there would be no benefit to pushing the locks into the
FSAL.
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
If the FSAL supports lock owners, then Ganesha expects it to manage conflicts
between lock owners. Also, it is critical for proper management when several
lock owners have an overlapping shared/read lock and one client releases the
lock (if the FSAL supports locks but not lock owners, Ganesha must determine
the union of all locks and dynamically maintain this into the FSAL – it’s a
messy process…).
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
