All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@redhat.com>,
	"Trond.Myklebust" <trond.myklebust@fys.uio.no>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	NFSv3 list <linux-nfs@vger.kernel.org>
Subject: Re: [RFC] After nfs restart, locks can't be recovered which record by lockd before
Date: Thu, 14 Jan 2010 18:06:42 +0800	[thread overview]
Message-ID: <4B4EECB2.8050400@cn.fujitsu.com> (raw)
In-Reply-To: <4B4E16C3.4050206@oracle.com>

Hi Chuck,

Chuck Lever =E5=86=99=E9=81=93:
> On 01/13/2010 07:51 AM, Jeff Layton wrote:
>> On Wed, 13 Jan 2010 17:51:25 +0800
>> Mi Jinlong<mijinlong@cn.fujitsu.com>  wrote:
>>
>> Assuming you're using a RH-derived distro like Fedora or RHEL, then =
no.
>> statd is controlled by a separate init script (nfslock) and when you
>> run "service nfs restart" you're not restarting it. NSM notification=
s
>> are not sent and clients generally won't reclaim their locks.
>>
>> IOW, "you're doing it wrong". If you want locks to be reclaimed then
>> you probably need to restart the nfslock service too.
>=20
> Mi Jinlong is exercising another case we know doesn't work right, but=
 we
> don't expect admins will ever perform this kind of "down-up" on a nor=
mal
> production server.  In other words, we expect it to work this way, an=
d
> it's been good enough, so far.
>=20
> As Jeff points out, the "nfs" and the "nfslock" services are separate=
=2E
> This is because "nfslock" is required for both client and server side
> NFS, but "nfs" is required only on the server.  This split also dicta=
tes
> the way sm-notify works, since it has to behave differently on NFS
> clients and servers.
>=20
> Two other points:
>=20
>   + lockd would not restart itself in this case if there happened to =
be
> NFS mounts on that system

  When testing, i find nfs restart will cause lockd restart.
  I find some codes which cause the lock stop when nfs stop.

 At kernel 2.6.18, fs/lockd/svc.c
 ...
 354         if (nlmsvc_users) {
 355                 if (--nlmsvc_users)
 356                         goto out;
 357         } else
 358                 printk(KERN_WARNING "lockd_down: no users! pid=3D%=
d\n", nlmsvc_pid);
 ...
 366=20
 367         kill_proc(nlmsvc_pid, SIGKILL, 1);
 ...
=20
 At kernel 2.6.18, fs/lockd/svc.c
 ...
 344         if (nlmsvc_users) {
 345                 if (--nlmsvc_users)
 346                         goto out;
 347         } else {
 348                 printk(KERN_ERR "lockd_down: no users! task=3D%p\n=
",
 349                         nlmsvc_task);
 350                 BUG();
 351         }
 ....
 357         kthread_stop(nlmsvc_task);
 358         svc_exit_thread(nlmsvc_rqst);
 ...

 As above, when nlmsvc_users <=3D 1, the lockd will be killed.

>=20
>   + lockd doesn't currently poke statd when it restarts to tell it to
> send reboot notifications, but it probably should

  Yes, I agree with you. But now, when some reason cause lockd restart =
but
  statd not restart, locks which hold before will lost.

  Maybe, the kernel should fix this.

>=20
> We know that lockd will start up when someone mounts the first NFS
> share, or when the NFS server is started.  If lockd sent statd an
> SM_SIMU_CRASH (or something like it) every time it cold started, stat=
d
> could send reboot notifications at the right time on both servers and
> clients without extra logic in the init scripts, and we wouldn't need
> that kludge in sm-notify to know when a machine has rebooted.

  What's the meaning of cold start?? System reboot? Or statd reboot?

  I want to know when using cammond "service nfslock restart" restart t=
he=20
  nfslock service(means restart statd and lockd), will the statd call s=
m-notify=20
  to notify other client? Or don't?

  At RHEL5 and Fedora, the sm-notify will be call and send SM-NOTIFY ev=
ery time=20
  when nfslock restart.

thanks,
Mi Jinlong


  reply	other threads:[~2010-01-14 10:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13  9:51 [RFC] After nfs restart, locks can't be recovered which record by lockd before Mi Jinlong
2010-01-13 12:51 ` Jeff Layton
     [not found]   ` <20100113075155.5c409567-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2010-01-13 18:53     ` Chuck Lever
2010-01-14 10:06       ` Mi Jinlong [this message]
2010-01-14 16:13         ` Chuck Lever
2010-01-15  9:35           ` Mi Jinlong
2010-01-15 16:12             ` Chuck Lever
2010-01-18 10:51               ` Mi Jinlong
2010-01-18 16:17                 ` Chuck Lever
2010-01-19 10:36                   ` Mi Jinlong
2010-01-14  9:41     ` Mi Jinlong
2010-01-14 12:10       ` Jeff Layton
     [not found]         ` <20100114071036.09583f4a-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-01-15  9:28           ` Mi Jinlong

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=4B4EECB2.8050400@cn.fujitsu.com \
    --to=mijinlong@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@redhat.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.