One more doubt on this, because I am still not sure why ganesha cannot call
SM_NOTIFY, the way it calls SM_MON, SM_UNMON, etc.
Why can't we bump up the state number and call SM_NOTIFY (or just call
SM_SIMU_CRASH which is combination of the two ops) on local rpc.statd every
time we start ganesha? This will ask statd to send notify messages to all
the clients explicitly. If the monitored client list is empty (first
start), no notifications will be sent. If there are any clients in the
list, they will be notified. If the client does not have server in the
monitored list or the lock is not in the client cache, the notify signal
will be ignored, otherwise it will try to reclaim the lock.
- Sriram
On Tue, Oct 17, 2017 at 9:59 PM, sriram patil <spsrirampa...@gmail.com>
wrote:
> Ohh okay. Thanks for the help Frank and Malahal. I will look into this
> further. I will update on this once I get everything working.
>
> - Sriram
>
> On Tue, Oct 17, 2017 at 7:22 PM, Frank Filz <ffilz...@mindspring.com>
> wrote:
>
>> Yes, good point. That SHOULD all be covered by the scripting. To be
>> honest, I haven’t actually looked at the various sample scripts, for
>> development, I run a modified init.d script from the Ganesha 1.5 timeframe…
>>
>>
>>
>> I think sm-notify –f does update the NSM state number.
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Monday, October 16, 2017 11:02 PM
>> *To:* Frank Filz <ffilz...@mindspring.com>
>> *Cc:* Malahal Naineni <mala...@gmail.com>; nfs-ganesha-devel@lists.source
>> forge.net
>>
>> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>>
>>
>>
>> Even with this, unless we can change the rpc.statd state, the SM_NOTIFY
>> will not trigger any lock reclaims on the client side. I know the state
>> number should be even/odd depending on whether the server is down/up. Is it
>> safe to change the state number manually and then run sm_notify.ganesha?
>> How can one guarantee the NSM/NLM semantics in case of server crash in the
>> current scenario?
>>
>>
>>
>> On Tue, Oct 17, 2017 at 12:37 AM, Frank Filz <ffilz...@mindspring.com>
>> wrote:
>>
>> The model of rpc.statd is that the client talks to its rpc.statd and the
>> server talks to its rpc.statd, and the two rpc.statd talk to each other… So
>> the sm_notify utility is used outside Ganesha essentially as part of
>> rpc.statd to send the SM_NOTIFY requests. Theoretically, the server host
>> should send SM_NOTIFY on reboot, of course since Ganesha is user space, it
>> can crash without a server reboot.
>>
>>
>>
>> There has been some discussion about pulling rpc.statd into Ganesha which
>> would have some advantages and then it would make sense for Ganesha to
>> issue the SM_NOTIFY.
>>
>>
>>
>> Note that sm_notify queries a directory created and managed by rpc.statd.
>> Ganesha does not manage the directory that persists the NLM client
>> information.
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Monday, October 16, 2017 11:32 AM
>> *To:* Malahal Naineni <mala...@gmail.com>
>> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
>> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>>
>>
>>
>> Hi,
>>
>>
>>
>> I had a follow up question on this. I was looking into NSM related
>> implementation as well. I see that ganesha handles the notify messages from
>> clients and releases all the locks. But, when the server crashes/restarts
>> it does not explicitly notify clients. I did not find any code sending
>> SM_NOTIFY.
>>
>>
>>
>> There is a separate binary, sm_notify.ganesha, but I am not sure why is
>> it a separate binary instead of making a clnt_call with SM_NOTIFY.
>>
>>
>>
>> There are respectives functions in nsm.h for every NSM proc, but
>> nsm_notify is not implemented.
>>
>>
>>
>> Is this handled in some other way? Are the service scripts supposed to
>> use sm_notify.fanesha binary in some way or it is just test code?
>>
>>
>>
>> Thanks,
>>
>> Sriram
>>
>>
>>
>> On 16-Oct-2017 11:55 PM, "sriram patil" <spsrirampa...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> On 16-Oct-2017 12:50 PM, "Malahal Naineni" <mala...@gmail.com> wrote:
>>
>> NFSv3 protocol doesn't deal with locks, so there is no mention of grace
>> period. NLM protocol is used in NFSv3 environments, so grace period does
>> exist in NLM.
>>
>>
>>
>> >> So, NFSv3 only server will mostly run with "Graceless = true"
>>
>>
>>
>> The above is true if you run ganesha with NFSv3 and disable NLM. This is
>> not the usual case! We do run with NLM enabled, so we have grace period
>> defined even in our NFSv3 only environments.
>>
>>
>>
>> Okay. So, NFSv4 grace period is used for NLM in case of NFSv3. The
>> nlm_grace_tv confused me. Thanks for clarifying.
>>
>>
>>
>>
>>
>> >> So, nfs4_Lock should actually use the NLM server grace period
>>
>>
>>
>> You mean nlm4_Lock? I don't see a separate NLM grace period in
>> ganesha. nlm_grace_tv seems to be just grace time (not period). It should
>> be removed as it is NOT used at all.
>>
>>
>>
>> True. Will send this patch.
>>
>>
>>
>>
>>
>> Regards, Malahal.
>>
>>
>>
>>
>>
>> On Mon, Oct 16, 2017 at 11:35 AM, sriram patil <spsrirampa...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I was looking into NLM locking code for NFSv3. According to NLM/NSM
>> protocols specifications, when server restarts, the client should send
>> nlm4_Lock request with "reclaim" flag set. This reclaim is honored
>> only if "NLM server" is in grace period. However, this code in
>> nlm4_Lock function actually looks if the NFS server is in grace
>> period, instead of checking NLM server.
>>
>> Also, NLM is used in case of NFSv3 and NFSv3 specs do not define grace
>> period. So, NFSv3 only server will mostly run with "Graceless = true"
>> and the lock recovery will not work on server restarts.
>>
>> So, nfs4_Lock should actually use the NLM server grace period
>> (nlm_grace_tv) for handling reclaims. Since NFSv4 does not use NLM at
>> all, we can assume that NLM code path is useful only for NFSv3.
>>
>> Does this look like a genuine issue?
>>
>> Thanks,
>> Sriram
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Nfs-ganesha-devel mailing list
>> Nfs-ganesha-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>
>>
>>
>>
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>>
>> Virus-free. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>>
>>
>>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
