From: Bryan Schumaker <bjschuma@netapp.com>
To: Pavel <free.lan.c2.718r@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: clients fail to reclaim locks after server reboot or manual sm-notify
Date: Mon, 14 Nov 2011 16:55:43 -0500 [thread overview]
Message-ID: <4EC18E5F.4080101@netapp.com> (raw)
In-Reply-To: <4EC1678D.902@netapp.com>
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).
It might also be useful if you could share the /etc/exports file on the
server.
Thanks!
- Bryan
>
> - Bryan
>
> On Mon 14 Nov 2011 12:11:56 PM EST, Pavel wrote:
>> Hi! I'm trying to set up an NFS server (particularly an A/A NFS cluster) and
>> having issues with locking and reboot notifications. These are the tests I have
>> done:
>>
>> 1. The simplest test includes single NFS server machine (Debian Squeeze),
>> running nfs-kernel-server (nfs-utils 1.2.2-4) and a single client machine (same
>> OS), that mounts a share with “-o 'vers=3'” option. From the client I lock some
>> file on share using 'testlk -w <filename>' (testlk from nfsutils/tools/locktest)
>> so that a corresponding file appears in /var/lib/nfs/sm/ on server. Then I
>> reboot the server and this is what I get in client logs:
>>
>> lockd: request from 127.0.0.1, port=1007
>> lockd: SM_NOTIFY called
>> lockd: host nfs-server1 (192.168.0.101) rebooted, cnt 2
>> lockd: get host nfs-server1
>> lockd: get host nfs-server1
>> lockd: release host nfs-server1
>> lockd: reclaiming locks for host nfs-server1
>> lockd: rebind host nfs-server1
>> lockd: call procedure 2 on nfs-server1
>> lockd: nlm_bind_host nfs-server1 (192.168.0.101)
>> lockd: rpc_call returned error 13
>> lockd: failed to reclaim lock for pid 1555 (errno -13, status 0)
>> NLM: done reclaiming locks for host nfs-server1
>> lockd: release host nfs-server1
>>
>> 2. As I'm building a cluster I'll need to notify clients when NFS resource
>> migrates (since it is an A/A cluster nfs-kernel-server is always running on all
>> nodes and shares migrate using exportfs resource agent), but manually calling
>> sm-notify ('sm-notify -f -v <virtual IP of share>') from either the initial for
>> that share or backup node results in the following (client logs):
>>
>> lockd: request from 127.0.0.1, port=637
>> lockd: SM_NOTIFY called
>> lockd: host B (192.168.0.110) rebooted, cnt 2
>> lockd: get host B
>> lockd: get host B
>> lockd: release host B
>> lockd: reclaiming locks for host B
>> lockd: rebind host B
>> lockd: call procedure 2 on B
>> lockd: nlm_bind_host B (192.168.0.110)
>> lockd: server in grace period
>> lockd: spurious grace period reject?!
>> lockd: failed to reclaim lock for pid 2508 (errno -37, status 4)
>> NLM: done reclaiming locks for host B
>> lockd: release host B
>>
>> even though grace period is intended for lock reclamation. B/w after such
>> invocation no files, corresponding to the notified clients, appear in
>> /var/lib/nfs/sm/ on server for about 10 minutes, if I try locking from any of
>> these notified clients, even though locking itself is ok. Locking from other
>> clients generates files for them instantly.
>>
>> As of the rest: simple concurrent lock tests from couple of clients work fine as
>> well as server frees locks of rebooted clients.
>>
>> I'm new to NFS an may be missing obvious things, but I've already spent several
>> days googling around, but don't seem to find any solution.
>> Any help or guidance is highly appreciated. Thanks!
>>
>> --
>> 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
>
> --
> 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-14 21:56 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 [this message]
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
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=4EC18E5F.4080101@netapp.com \
--to=bjschuma@netapp.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.