<br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 9:19 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
> Oh, OK. Looking at the code in xlators/nfs/server/src/nlm4.c.... Looks<br>
> like it's probably just using the same statd as the kernel server--the<br>
> one installed as a part of nfs-utils, which by default puts its state in<br>
> /var/lib/nfs/statd/.<br>
><br>
> So if you want failover to work, then the contents of<br>
> /var/lib/nfs/statd/ has to be made available to the server that takes<br>
> over somehow.<br>
<br>
</div></div>This statd data and the implementation of the NLM protocol is not<br>
something I am very familiar with. But Rajesh (on CC) explained a little<br>
about it and informed me that the current NLM implementation indeed does<br>
not support transparent fail-over yet.<br>
<div class="im"><br></div></blockquote><div><br></div><div>The NLM implementation in gluster is stateless for all practical reasons (all locks are translated to lk() FOPs on the bricks). However we just use / depend on the RHEL rpc.statd -- which is not clustered. If the RHEL rpc.statd is replaced with a "clustered" statd, Gluster's NLM should "just work" even in failovers (by making a failover appear as a server reboot and kick off NLM's lock recovery) -- which may not be ideal and efficient, but should be functional.</div>
<div><br></div><div>Avati</div><div><br></div></div>