public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Sachin S. Prabhu" <sprabhu@redhat.com>
To: linux-nfs@vger.kernel.org
Subject: Virtual IPs and blocking locks
Date: Fri, 15 May 2009 15:48:22 +0100	[thread overview]
Message-ID: <4A0D80B6.4070101@redhat.com> (raw)

We have had a few reported cases of problems using blocking locks on nfs shares 
mounted using virtual ips. In these cases, the NFS server was using a floating 
ip for clustering purposes.

Please consider the transaction below

NFS client: 10.33.8.75
NFS Server:
Primary IP : 10.33.8.71
Floating IP:  10.33.8.77

$ tshark -r block-virtual.pcap -R 'nlm'
19   2.487622   10.33.8.75 -> 10.33.8.77   NLM V4 LOCK Call FH:0x6176411a svid:4 
pos:0-0
22   2.487760   10.33.8.77 -> 10.33.8.75   NLM V4 LOCK Reply (Call In 19) 
NLM_BLOCKED
33   2.489518   10.33.8.71 -> 10.33.8.75   NLM V4 GRANTED_MSG Call FH:0x6176411a 
svid:4 pos:0-0
36   2.489635   10.33.8.75 -> 10.33.8.71   NLM V4 GRANTED_MSG Reply (Call In 33)
46   2.489977   10.33.8.75 -> 10.33.8.71   NLM V4 GRANTED_RES Call NLM_DENIED
49   2.490096   10.33.8.71 -> 10.33.8.75   NLM V4 GRANTED_RES Reply (Call In 46)

19 - A lock request is sent from the client to the floating ip.
22 - A NLM_BLOCKED request is sent back by the Floating ip to the client.
33 - Server Primary IP address returns a NLM_GRANTED using the async callback 
mechanism.
36 - Ack for GRANTED_MSG in 33.
47 - Client returns a NLM_DENIED to the SERVER. This is done since it doesn't 
match the locks requested.
49 - Ack for GRANTED_RES in 46.

In this case, the GRANTED_MSG is sent by the primary ip as determined by the 
routing table. This lock grant is rejected by the server since the ip address of 
the server doesn't match the ip address of the server against which the request 
was made. The locks are eventually granted after a 30 second poll timeout on the 
client.

Similar problems are also seen when nfs shares are exported from GFS filesystems 
since GFS uses deferred locks.

The problem was introduced by commit 5ac5f9d1ce8492163dbde5d357dc5d03becf7e36 
which adds a check for the server ip address. This causes a regression for 
clients which mount off a virtual ip address from the server.

A possible fix for this issue is to use the server ip address in the nlm_lock.oh 
field used to make the request and compare it to the nlm_lock.oh returned in the 
GRANTED_MSG call instead of checking the ip address of the server calling making 
the GRANTED_MSG call.

Sachin Prabhu

             reply	other threads:[~2009-05-15 14:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-15 14:48 Sachin S. Prabhu [this message]
2009-05-15 16:50 ` Virtual IPs and blocking locks Rob Gardner
2009-05-18 13:41   ` Sachin S. Prabhu
2009-05-18 13:46     ` Trond Myklebust
2009-05-18 13:55     ` Rob Gardner
2009-05-19 20:43       ` Huge race in lockd for async lock requests? Rob Gardner
2009-05-19 21:33         ` Tom Talpey
2009-05-20  6:55         ` Rob Gardner
2009-05-20 14:00           ` Tom Talpey
     [not found]             ` <4a140d0a.85c2f10a.53bc.0979-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 14:14               ` Tom Talpey
     [not found]                 ` <4a14106e.48c3f10a.7ce3.0e55-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 23:20                   ` Rob Gardner
2009-05-20 16:37               ` Rob Gardner
2009-05-28 20:05                 ` J. Bruce Fields
2009-05-28 21:34                   ` Rob Gardner
2009-05-29  0:26                     ` J. Bruce Fields
2009-05-29  2:59                       ` Rob Gardner
2009-05-29 13:22                         ` Tom Talpey
     [not found]                           ` <4a1fe1c0.06045a0a.165b.5fbc-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-29 15:24                             ` Rob Gardner
2009-05-29 19:14                               ` J. Bruce Fields

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=4A0D80B6.4070101@redhat.com \
    --to=sprabhu@redhat.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