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: Tue, 15 Aug 2006 14:32:45 -0400 [thread overview]
Message-ID: <44E2134D.7000809@redhat.com> (raw)
In-Reply-To: <44E09DDA.9070302@redhat.com>
There were few replies emails that didn't arrive at nfs list last week
but got archived in:
* why switching to fsid
https://www.redhat.com/archives/cluster-devel/2006-August/msg00090.html
* cluster script failover sequence)
https://www.redhat.com/archives/cluster-devel/2006-August/msg00087.html
To help people understand the patch logic, the following is a sample
failover flow:
Assume we have server_A and server_B. Server_A is a multi-home NFS
server with two ip address 10.10.10.1 and 10.10.1.1 where:
shell> cat /etc/exports
/mnt/ext3/exports *(fsid=1234,sync,rw)
/mnt/gfs1/exports *(fsid=1236,sync,rw)
It is expected ext3 filesystem served by 10.10.1.1 and gfs served by
10.10.10.1. If we ever want to move ext3 over to server_B, the sequence
would be:
On server_A:
1. Tear down 10.10.1.1
2. Un-export ext3 exports
3. echo 1234 > /proc/fs/nfsd/nlm_unlock
4. Umount ext3
On sever_B:
1. Mount ext3 fs
2. echo 1234 > /proc/fs/nfsd/nlm_set_igrace
3. Export ext3 exports
4. Bring up 10.10.1.1
5. Sending restricted reclaim notifications via 10.10.1.1
Step 5 is implemented based on the ha-callout program as described in
"man rpc.statd". What our cluster suite (user mode script) will do (if
this patch set gets accepted) is to bring up rpc.statd on both servers
with ha-callout program.
On server_A, the ha-callout program constructs two sm directories
(sm-10.10.10.1 and sm-10.10.1.1) that can be accessed by both servers.
This is normally done by placing the directories on the filesystem that
will get moved over. The original /var/lib/nfs/statd/sm stays in its
default place in case of server_A ends up with a real reboot (or crash).
When server_B takes over, it sends out an one-time notice to all the
clients that has entries in sm-10.10.1.1 directory.
Note that the code of ha-callout program (will be done by our cluster
suite) actually can be integrated into statd within nfs-utils package.
However, I would like to keep the changes made into mainline nfs code as
miminum as possible at this moment.
-- Wendy
next prev parent reply other threads:[~2006-08-15 18:32 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
2006-08-15 18:32 ` Wendy Cheng [this message]
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=44E2134D.7000809@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).