All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "Trond.Myklebust" <trond.myklebust@fys.uio.no>,
	NFSv3 list <linux-nfs@vger.kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [RFC] server's statd and lockd will not sync after its nfslock restart
Date: Wed, 16 Dec 2009 17:46:49 +0800	[thread overview]
Message-ID: <4B28AC89.9000903@cn.fujitsu.com> (raw)
In-Reply-To: <20091215124121.GB32017@fieldses.org>



J. Bruce Fields :
> On Tue, Dec 15, 2009 at 06:02:11PM +0800, Mi Jinlong wrote:
>> Hi,
>>
>> When testing the NLM at the latest kernel(2.6.32),  i find a bug.
>> When a client hold locks, after server restart its nfslock service, 
>> server's statd will not synchronize with lockd.
>> If server restart nfslock twice or more, client's lock will be lost.
>>
>> Test process:
>>
>>   Step1: client open nfs file.
>>   Step2: client using fcntl to get lock.
>>   Step3: server restart it's nfslock service.
> 
> I don't know what you mean; what did you actually do in step 3?

  I use command "service nfslock restart" at server.

  I mean, after server restart nfslock service, lockd and statd are not synchronizing.
  Because, after nfslock restart, server go into grace_period, and client's 
  reclaimed lock request will be processed by lockd. At this, client's host(the host struct)
  will be reused which is created before nfslock restart, but, the lockd don't 
  send a SM_MON to statd.

  After locks are reclaimed, server's lockd records client hold locks, but statd don't 
  monitor client.

 thanks,
 Mi Jinlong

> 
> --b.
> 
>> After step3, server's lockd records client holding locks, but statd's 
>> /var/lib/nfs/statd/sm/ directory is empty. It means statd and lockd are 
>> not sync. If server restart it's nfslock again, client's locks will be lost.
>>
>> The Primary Reason:
>>
>>   At step3, when client's reclaimed lock request is sent to server, 
>> client's host(the host struct) is reused but not be re-monitored at
>> server's lockd. After that, statd and lockd are not sync.
>>
>> Question:
>>
>> In my opinion, if lockd is allowed reuseing the client's host, it should
>> send a SM_MON to statd when reuse. If not allowed, the client's host should 
>> be destroyed immediately.
>>  
>> What should lockd to do?  Reuse ? Destroy ? Or some other action?
>>
>>
>> thanks,
>>
>> Mi Jinlong
>>
> 
> 

-- 
Regards
Mi Jinlong


  reply	other threads:[~2009-12-16  9:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-15 10:02 [RFC] server's statd and lockd will not sync after its nfslock restart Mi Jinlong
2009-12-15 12:41 ` J. Bruce Fields
2009-12-16  9:46   ` Mi Jinlong [this message]
2009-12-15 15:10 ` Chuck Lever
2009-12-16 10:27   ` Mi Jinlong
2009-12-16 13:49     ` Jeff Layton
     [not found]       ` <20091216084902.64f722ad-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2009-12-17  9:34         ` Mi Jinlong
2009-12-16 19:33     ` Chuck Lever
2009-12-17 10:07       ` Mi Jinlong
2009-12-17 16:18         ` Chuck Lever
2009-12-17 20:14           ` J. Bruce Fields
2009-12-17 20:35             ` Chuck Lever
2009-12-17 20:27           ` Trond Myklebust
2009-12-17 20:34             ` Chuck Lever
2009-12-17 20:48               ` Trond Myklebust
2009-12-17 23:14           ` Neil Brown
     [not found]             ` <20091218101438.48eb06a4-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-12-18 15:18               ` Chuck Lever
2009-12-19 16:42                 ` Steve Dickson

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=4B28AC89.9000903@cn.fujitsu.com \
    --to=mijinlong@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /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.