From: Peter Staubach <staubach@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: hexf <hexiaofeng-U4AKAne5IzAR5TUyvShJeg@public.gmane.org>,
linux-nfs@vger.kernel.org
Subject: Re: about NLM/NSM
Date: Mon, 27 Oct 2008 17:14:38 -0400 [thread overview]
Message-ID: <49062F3E.6090206@redhat.com> (raw)
In-Reply-To: <20081027201323.GA25467@fieldses.org>
J. Bruce Fields wrote:
> On Mon, Oct 27, 2008 at 03:22:57PM -0400, Peter Staubach wrote:
>
>> J. Bruce Fields wrote:
>>
>>> On Mon, Oct 27, 2008 at 02:49:27PM +0800, hexf wrote:
>>>
>>>
>>>> We are using nfsv3. Now we meet a demand. If a client which hold a
>>>> lock crash, after it reboot, its statd daemon can notify the nfs
>>>> server to release the lock. But if this client will not reboot for
>>>> some reason(or will reboot after a long time), then the lock it
>>>> holding will not be released.In nfsv3 and nlmv4,it seems there is no
>>>> time-out mechnism for this situation. How would we solve this
>>>> question? My colleague advise me to modify the code of NLM/NSM to meet
>>>> this demand,but is seems quite a complicated work.Can you give me some
>>>> advice?
>>>>
>>>>
>>> It might be possible to modify the server so that it dropped all locks
>>> from a client it hadn't heard from in a while. However, nfsv2/v3
>>> clients are not required to contact the server regularly while they hold
>>> locks. So you may end up revoking locks held by perfectly good
>>> functioning clients.
>>>
>>> As an ugly workaround, rebooting the server will clear the problem, as
>>> it will notify clients to recover their locks on restart, and any dead
>>> clients will fail to recover their locks.
>>>
>>>
>>>
>> Didn't Wendy Cheng submit some patches to implement a
>> "clearlocks" sort of functionality? What happened with
>> them?
>>
>
> Yes, but that's motivated by the case of migrating all clients using one
> export; so it'll drop all locks held on a single filesystem, or all
> locks acquired using a single server (not client!) ip address.
>
> So if we want some finer-grained interface then that's yet to be
> designed.
>
Sorry, I guess that I was remembering incorrectly. I was
thinking that she was looking for something like the clearlocks
functionality so that file systems could be migrated around
cleanly.
It seems for this situation, we could use this sort of variation.
ps
next prev parent reply other threads:[~2008-10-27 21:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-27 6:49 about NLM/NSM hexf
2008-10-27 18:55 ` J. Bruce Fields
2008-10-27 19:22 ` Peter Staubach
2008-10-27 20:13 ` J. Bruce Fields
2008-10-27 21:14 ` Peter Staubach [this message]
2008-10-27 21:17 ` J. Bruce Fields
2008-10-27 21:20 ` Peter Staubach
2008-10-27 22:01 ` J. Bruce Fields
2008-10-28 17:31 ` Frank Filz
2008-10-29 1:20 ` Feng Shuo
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=49062F3E.6090206@redhat.com \
--to=staubach@redhat.com \
--cc=bfields@fieldses.org \
--cc=hexiaofeng-U4AKAne5IzAR5TUyvShJeg@public.gmane.org \
--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