From: Bryan Schumaker <bjschuma@netapp.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Pavel <free.lan.c2.718r@gmail.com>,
linux-nfs@vger.kernel.org, "J. Bruce Fields" <bfields@redhat.com>
Subject: Re: clients fail to reclaim locks after server reboot or manual sm-notify
Date: Wed, 16 Nov 2011 09:25:01 -0500 [thread overview]
Message-ID: <4EC3C7BD.6060407@netapp.com> (raw)
In-Reply-To: <20111115221623.GA12453@fieldses.org>
On Tue 15 Nov 2011 05:16:23 PM EST, J. Bruce Fields wrote:
> On Tue, Nov 15, 2011 at 04:48:57PM -0500, Bryan Schumaker wrote:
>> On 11/15/2011 10:50 AM, Pavel wrote:
>>> Bryan Schumaker <bjschuma@...> writes:
>>>
>>>>
>>>> On Mon 14 Nov 2011 02:10:05 PM EST, Bryan Schumaker wrote:
>>>>> Hello Pavel,
>>>>>
>>>>> What kernel version is Debian using? I haven't been able to reproduce the
>>> problem using 3.0 (But I'm on
>>>> Archlinux, so there might be other differences).
>>>
>>> Thanks, Bryan, for your reply.
>>>
>>> Debian is using Linux kernel version 2.6.32 - I haven't upgraded it.
>>>
>>>> It might also be useful if you could share the /etc/exports file on the
>>>> server.
>>>>
>>>> Thanks!
>>>>
>>>> - Bryan
>>>
>>> Thank you for the question - that was my rude mistake. For managing exports I'm
>>> using OCF resource agent 'exportfs'. It uses Linux build-in command 'exportfs'
>>> to export shares and /etc/exports file is empty. However Heartbeat starts much
>>> later than NFS...Now it is clear why this wasn't working. Setting up share that
>>> doesn't rely on Heartbeat resources, resolves the issue.
>>>
>>> Still though, the first test was just to make sure NFS functions the way it is
>>> supposed to, and not the goal - the second/main question remains open. When I
>>> run sm-notify in this case, shares are already exported and all the other needed
>>> resources are available as well. Why doesn't sm-notify work? It doesn't work
>>> even in case of single server test. As of using files from /var/lib/nfs/sm/ when
>>> notifying clients from the other node in cluster, it should be okay with -v
>>> option of sm-notify, because it is a common practice to store the whole
>>> /var/lib/nfs folder on shared storage in Active/Passive clusters and trigger sm-
>>> notify from the active node. It would be awesome if you could give me a clue.
>>
>> I'm seeing the same thing you are using some Debian VMs I set up yesterday afternoon. It does look like the server is replying with NLM_DENIED_GRACE_PERIOD when sm-notify is used. Bruce, any idea what's going on here?
>
> Sorry, I'm having trouble keeping up.... What exactly do you do, on
> which machine, and what do you then see happen?
Here is what I'm doing (On debian with 2.6.32):
- (On Client) Mount the server: `sudo mount -o vers=3
192.168.122.202:/home/bjschuma /mnt`
- (On Client) Lock a file using nfs-utils/tools/locktest: `./testlk
/mnt/test`
- (On Server) Call sm-notify with the server's IP address: `sudo
sm-notify -f -v 192.168.122.202`
- dmesg on the client has this message:
lockd: spurious grace period reject?!
lockd: failed to reclaim lock for pid 2099 (errno -37, status 4)
- (In wireshark) The client sends a lock request with the "Reclaim" bit
set to "yes" but the server replies with "NLM_DENIED_GRACE_PERIOD".
Shouldn't the server be allowing the lock reclaim? When I tried
yesterday using 3.0 it only triggered DNS packets, I tried again a few
minutes ago and got the same results that I did using .32.
- Bryan
>
> --b.
>
>>
>> When I try using my Linux 3.0 / Archlinux machines I don't see any NLM requests due to sm-notify. I'm not sure that's correct...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-11-16 14:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 17:11 clients fail to reclaim locks after server reboot or manual sm-notify Pavel
2011-11-14 19:10 ` Bryan Schumaker
2011-11-14 21:55 ` Bryan Schumaker
2011-11-15 15:50 ` Pavel
2011-11-15 17:19 ` Pavel
2011-11-15 21:48 ` Bryan Schumaker
2011-11-15 22:16 ` J. Bruce Fields
2011-11-16 14:25 ` Bryan Schumaker [this message]
2011-11-16 14:58 ` Pavel
2011-11-16 15:30 ` J. Bruce Fields
2011-11-16 17:15 ` Pasha Z
2011-11-16 17:28 ` J. Bruce Fields
2011-11-16 17:37 ` Bryan Schumaker
2011-11-16 19:09 ` Pavel A
2011-11-16 20:08 ` J. Bruce Fields
2011-11-16 20:21 ` Bryan Schumaker
2011-11-16 21:56 ` Pavel A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC3C7BD.6060407@netapp.com \
--to=bjschuma@netapp.com \
--cc=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=free.lan.c2.718r@gmail.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.