From: Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [NFS] [PATCH 2/5] NLM failover - per fs grace period
Date: Mon, 14 Aug 2006 11:59:22 -0400 [thread overview]
Message-ID: <44E09DDA.9070302@redhat.com> (raw)
In-Reply-To: <1155570281.5664.84.camel@localhost>
Trond Myklebust wrote:
>On Mon, 2006-08-14 at 02:00 -0400, Wendy Cheng wrote:
>
>
>>This change enables per NFS-export entry lockd grace period. The
>>implementation is based on a global single linked list nlm_servs that
>>contains entries of fsid info. It is expected this would not be a
>>frequent event. The nlm_servs list should be short and the entries
>>expire within a maximum of 50 seconds. The grace period setting follows
>>the existing NLM grace period handling logic and is triggered via
>>echoing the NFS export filesystem id into /proc/fs/nfsd/nlm_set_igrace
>>file as:
>>
>>shell> echo 1234 > /proc/fs/nfsd/nlm_set_igrace
>>
>>
>
>I still don't find the above interface convincing.
>
>Firstly, as I already told you, the NSM protocol does not allow you to
>set only a single filesystem in grace. Clients get notified of server
>reboots, not filesystem reboots: if they try to reclaim locks and find
>out that some of filesystems they have mounted will not allow them to do
>so, then they _will_ get confused and start dropping locks that would
>otherwise be perfectly valid.
>
>
I'll check into Linux client code to see what's going on. But please be
aware that the individual filesystem grace period goes with floating ip.
You notify (nfs) client by floating ip address, NOT by filesystem id
(but set the grace period in server via fsid).
Say you expect nfs requests going into floating ip 10.10.1.1 that will
handle exported fsid 1234 and 1235. On server, you do /proc entries
based on 1234 and 1235 and you notify client about 10.10.1.1.
>Secondly, with the above interface, you have to export the filesystem
>first, and then set the grace period.
>
No, you don't. The changes and code has nothing to do with export. It
just adds the numerical fsid into a global array (nlm_servs). When lock
requests finally arrive (later), it extracts the filesystem id from the
filehandle to compare. It can be invoked before filesystem is exported.
-- Wendy
next prev parent reply other threads:[~2006-08-14 15:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-14 6:00 [Cluster-devel] [PATCH 2/5] NLM failover - per fs grace period Wendy Cheng
2006-08-14 15:44 ` [Cluster-devel] Re: [NFS] " Trond Myklebust
2006-08-14 15:59 ` Wendy Cheng [this message]
2006-08-15 18:32 ` Wendy Cheng
2006-08-18 9:49 ` Greg Banks
2006-08-18 20:11 ` James Yarbrough
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=44E09DDA.9070302@redhat.com \
--to=wcheng@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).