Hi Frank/Malahal, Re-opening this thread.
On 06/24/2015 04:47 AM, Frank Filz wrote: > Note that the way Ganesha handles the epoch for clientids is structured in a > way that Ganesha doesn't have to be party to the details. There is a command line option that allows and external actor (presumably the startup script) to pass Ganesha a unique clientid epoch for each instance. This epoch should include some kind of node identifier for a cluster, and some kind of time element (either a timestamp or a counter that is incremented each time Ganesha starts on the node) so that each time Ganesha is started on a given node, a new epoch is assigned. A cluster global atomic counter would also work that would issue a new unique epoch to any Ganesha instance in the cluster. The epoch is 32 bits. We have a situation where in we need to support nfs-ganesha servers in a clustered environment with all the nodes ntp-configured. So we cannot change and set different epoch values for each of them. The only work-around we are left with is to start nfs-ganesha server with a delay on each node of the cluster. But that doesn't entirely guarantee that nfs-ganesha servers start_time will not collide especially during failover and restart scenarios. So we would like to know if there is any better way to handle and prevent this problem. May be ServerEpoch could contain 'boot_time + node_id/ip_addr(which can be provided via a config option)'. Please share your thoughts. Thanks, Soumya ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
