In HA environments the SM_NOTIFY has to be sent from the correct server
address. For Ganesha, many of the HA functions are managed by scripts outside
Ganesha, and SM_NOTIFY has to be part of that.
You are right that in a single server environment, that it would be convenient
for Ganesha to send the SM_NOTIFY.
Frank
From: sriram patil [mailto:spsrirampa...@gmail.com]
Sent: Tuesday, October 17, 2017 9:46 AM
To: Frank Filz <ffilz...@mindspring.com>
Cc: Malahal Naineni <mala...@gmail.com>; nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] NLM locks recovery issue
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
<mailto: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
<mailto: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
<mailto:spsrirampa...@gmail.com> ]
Sent: Monday, October 16, 2017 11:02 PM
To: Frank Filz <ffilz...@mindspring.com <mailto:ffilz...@mindspring.com> >
Cc: Malahal Naineni <mala...@gmail.com <mailto:mala...@gmail.com> >;
nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.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
<mailto: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
<mailto:spsrirampa...@gmail.com> ]
Sent: Monday, October 16, 2017 11:32 AM
To: Malahal Naineni <mala...@gmail.com <mailto:mala...@gmail.com> >
Cc: nfs-ganesha-devel@lists.sourceforge.net
<mailto: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
<mailto:spsrirampa...@gmail.com> > wrote:
On 16-Oct-2017 12:50 PM, "Malahal Naineni" <mala...@gmail.com
<mailto: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
<mailto: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.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
www.avast.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
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
