Linux NFS development
 help / color / mirror / Atom feed
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



  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox