All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wendy Cheng <wcheng@redhat.com>
To: Neil Brown <neilb@suse.de>
Cc: linux-cluster@redhat.com, nfs@lists.sourceforge.net
Subject: Re: [NFS] [RFC] NLM lock failover admin interface
Date: Tue, 13 Jun 2006 03:00:11 -0400	[thread overview]
Message-ID: <1150182012.27203.42.camel@localhost.localdomain> (raw)
In-Reply-To: <17550.11870.186706.36949@cse.unsw.edu.au>

On Tue, 2006-06-13 at 13:17 +1000, Neil Brown wrote:

> So:
>  I think if we really want to "remove all NFS locks on a filesystem",
>  we could probably tie it into umount - maybe have lockd register some
>  callback which gets called just before s_op->umount_begin.

The "umount_begin" idea was one time on my list but got discarded. The
thought was that nfsd was not a filesystem, neither was lockd. How to
register something with VFS umount for non-filesystem kernel modules ?
Invent another autofs-like pseudo filesystem ? Mostly, not every
filesystem would like to get un-mounted upon failover (GFS, for example,
does not get un-mounted by our cluster suite upon failover).

>  If we want to remove all locks that arrived on a particular
>  interface, then we should arrange to do exactly that.  There are a
>  number of different options here. 
>   One is the multiple-lockd-threads idea.

Certainly a good option. To make it happen, we still need admin
interface. How to pass IP address from user mode into kernel - care to
give this some suggestions if you have them handy ? Should socket ports
get dynamics assigned ? Will we have scalibility issues ? 
 
>   One is to register a callback when an interface is shut down.
>   Another (possibly the best) is to arrange a new signal for lockd
>   which say "Drop any locks which were sent to IP addresses that are
>   no longer valid local addresses".

These, again, give individual filesystem no freedom to adjust what they
need upon failover. But I'll check them out this week - maybe there are
good socket layer hooks that I overlook. 

> 
> So those are my thoughts.  Do any of them seem reasonable to you?
> 

The comments are greatly appreciated. And hopefully we can reach
agreement soon.   

-- Wendy

  reply	other threads:[~2006-06-13  7:00 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   ` [NFS] " Wendy Cheng
2006-06-13  3:17 ` Neil Brown
2006-06-13  7:00   ` Wendy Cheng [this message]
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=1150182012.27203.42.camel@localhost.localdomain \
    --to=wcheng@redhat.com \
    --cc=linux-cluster@redhat.com \
    --cc=neilb@suse.de \
    --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.