All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wendy Cheng <wcheng@redhat.com>
To: James Yarbrough <jmy@sgi.com>
Cc: linux-cluster@redhat.com, nfs@lists.sourceforge.net
Subject: Re: [NFS] [RFC] NLM lock failover admin interface
Date: Mon, 12 Jun 2006 15:07:23 -0400	[thread overview]
Message-ID: <448DBB6B.7000408@redhat.com> (raw)
In-Reply-To: <448DA3F0.AF1C8540@sgi.com>

James Yarbrough wrote:

>>2. Adding a new flag into "exportfs" command, say "h", such that
>>
>>   "exportfs -uh *:/export_path"
>>
>>would un-export the entry and drop the NLM locks associated with the
>>entry.
>>    
>>
>
>This is fine for releasing the locks, but how do you plan to re-enter
>the grace period for reclaiming the locks when you relocate the export?
>And how do you intend to segregate the export for which reclaims are
>valid from the ones which are not?  How do you plan to support the
>sending of SM_NOTIFY?  This might be where a lockd per export has an
>advantage.
>
>  
>
Yeah, that's why Peter's idea (different lockd(s)) is also attractive. 
However, on the practical side, we don't plan to introduce kernel 
patches agressively. The approach is to be away from mainline NLM code 
base until we have enough QA cycles to make sure things work. The 
unexport part would allow other nfs services on the taken-over server 
un-interrupted. On the take-over server side, we currently do a global 
grace period. The plan has been to put a little delay before fixing 
take-over server's logic due to other NLM/posix lock issues - for 
example, the current (linux) NLM doesn't bother to call filesystem's 
lock method (which virtually disables any cluster filesystem's NFS 
locking across different NFS servers). However, if we have enough 
resources and/or volunteers, we may do these things in parallel. The 
following are planned:

Take-over server logic:
1. setup the statd sm file (currently /var/lib/nfs/statd/sm or the
    equivalent configured directory) properly.
2. rpc.statd is dispatched with "--ha-callout" option.
3. implement the ha-callout user mode program to create a seperate
    statd sm files for each exported ip.
4. export the target filesystem and set up grace period based on
    fsid (or devno). It will be used in NLM procedure calls by
    extracting the fsid (or devno) from nfs file handle to decide
    accepting or reject the not-reclaiming requests.
5. bring up the failover IP address.
6. send SM_NOTIFY to client machines using the configured sm
    directory created by the ha-callout program (rpc.statd -N -P).

Step 4 will be the counter-part of our unexport flag.

-- Wendy

 

  reply	other threads:[~2006-06-12 19:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-12  5:25 [RFC] NLM lock failover admin interface Wendy Cheng
2006-06-12  6:11 ` Wendy Cheng
2006-06-12 15:00 ` [Linux-cluster] " J. Bruce Fields
2006-06-12 15:44   ` [NFS] " Wendy Cheng
2006-06-12 16:20     ` [Linux-cluster] " Madhan P
2006-06-12 16:58       ` Madhan P
2006-06-12 18:09       ` [NFS] " Wendy Cheng
2006-06-12 17:23     ` [Linux-cluster] " Steve Dickson
2006-06-12 17:27 ` James Yarbrough
2006-06-12 19:07   ` Wendy Cheng [this message]
2006-06-13  3:17 ` Neil Brown
2006-06-13  7:00   ` [NFS] " Wendy Cheng
2006-06-13  7:08     ` Neil Brown
2006-06-14  6:54   ` [NFS] " Wendy Cheng
2006-06-14 11:36     ` Christoph Hellwig
2006-06-14 13:39       ` Wendy Cheng
2006-06-14 14:00     ` Wendy Cheng
2006-06-15 14:07       ` [NFS] " William A.(Andy) Adamson
2006-06-15 15:09         ` Wendy Cheng
2006-06-16  6:09         ` [Linux-cluster] " Neil Brown
2006-06-16 15:39           ` [NFS] " William A.(Andy) Adamson
2006-06-15  4:27     ` [NFS] " Neil Brown
2006-06-15  6:39       ` Wendy Cheng
2006-06-15  8:02         ` Neil Brown
2006-06-15 18:43           ` Wendy Cheng
2006-06-13 15:23 ` 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=448DBB6B.7000408@redhat.com \
    --to=wcheng@redhat.com \
    --cc=jmy@sgi.com \
    --cc=linux-cluster@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    /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.