From: Wendy Cheng <wcheng@redhat.com>
To: Frank van Maarseveen <frankvm@frankvm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
cluster-devel@redhat.com, Jeff Layton <jlayton@redhat.com>,
Neil Brown <neilb@suse.de>,
"J. Bruce Fields" <bfields@fieldses.org>,
nfs@lists.sourceforge.net
Subject: Re: [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover
Date: Fri, 27 Apr 2007 23:55:27 -0400 [thread overview]
Message-ID: <4632C5AF.7080500@redhat.com> (raw)
In-Reply-To: <20070427203444.GA28874@janus>
Frank van Maarseveen wrote:
>I'm quite interested in _any_ patch which would allow me to drop
>the locks obtained by NFS clients on a specific export, either by (1)
>"exportfs -uh" or by (2) "echo /some/path > /proc/fs/nfsd/nlm_drop_lock"
>as Neil mentioned.
>
>
Thanks for commenting on this. Opinions from users who will eventually
use these interfaces are always valued.
>[snip]
>
>
>I'd prefer (2) "echo /some/path > /proc/fs/nfsd/nlm_drop_lock" because:
>
>
To convert the first patch of this submitted series from "fsid" to
"/some/path" is a no-brainer, since we had gone thru several rounds of
similar changes. However, my questions (it is more of a Neil's question)
are, if I convert the first patch to do this,
1) then why do we still need the RPC drop-lock call in nfs-util ?
2) what should we do for the 2nd patch ? i.e., how do we communicate
with the take-over server it is time for its action, by RPC call or by
"echo /some/path > /proc/fs/nfsd/nlm_set_grace_or_whatever" ?
In general, I feel if we do this "/some/path" approach, we may as well
simply convert the 2nd patch from "fsid" to "/some/path". Then we would
finish this long journey.
-- Wendy
>- Tying the -h (drop locks) option to -u (unexport) is too restrictive IMO.
> For one thing, there's a bug in the linux NFS client locking code (I
> reported this earlier) which results in locks not being removed from
> the server. It was not too difficult to reproduce and programs on the
> client will wait forever due to this. To handle these kind of situations
> I need (2) on the server.
>
>- (2) may be useful for other NFS server setups: it is inherently more
> flexible.
>
>- (2) does not depend on nfs-utils. It's simpler.
>
>
>(*) virtual in this case means a UUID or IP based fsid= option and an
>additional IP address on eth0 per export entry, such, that it becomes
>possible to move an export entry + disk partition + local mount to
>different hardware without needing to remount it on all <large number>
>NFS clients.
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-04-28 3:45 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-05 21:50 [PATCH 0/4 Revised] NLM - lock failover Wendy Cheng
2007-04-11 17:01 ` J. Bruce Fields
2007-04-17 19:30 ` [Cluster-devel] " Wendy Cheng
2007-04-18 18:56 ` Wendy Cheng
2007-04-18 19:46 ` [Cluster-devel] " Wendy Cheng
2007-04-19 14:41 ` Christoph Hellwig
2007-04-19 15:08 ` Wendy Cheng
2007-04-19 7:04 ` [Cluster-devel] " Neil Brown
2007-04-19 14:53 ` Wendy Cheng
2007-04-24 3:30 ` Wendy Cheng
2007-04-24 5:52 ` Neil Brown
2007-04-26 4:35 ` Wendy Cheng
2007-04-26 5:43 ` Neil Brown
2007-04-27 2:24 ` Wendy Cheng
2007-04-27 6:00 ` Neil Brown
2007-04-27 11:15 ` Jeff Layton
2007-04-27 12:40 ` Neil Brown
2007-04-27 13:42 ` Jeff Layton
2007-04-27 14:17 ` Christoph Hellwig
2007-04-27 15:42 ` J. Bruce Fields
2007-04-27 15:36 ` Wendy Cheng
2007-04-27 16:31 ` J. Bruce Fields
2007-04-27 22:22 ` Neil Brown
2007-04-29 20:13 ` J. Bruce Fields
2007-04-29 23:10 ` Neil Brown
2007-04-30 5:19 ` Wendy Cheng
2007-05-04 18:42 ` J. Bruce Fields
2007-05-04 21:35 ` Wendy Cheng
2007-04-27 20:34 ` Frank van Maarseveen
2007-04-28 3:55 ` Wendy Cheng [this message]
2007-04-28 4:51 ` Neil Brown
2007-04-28 5:26 ` Marc Eshel
2007-04-28 12:33 ` Frank van Maarseveen
2007-04-27 15:12 ` Jeff Layton
2007-04-25 14:18 ` J. Bruce Fields
2007-04-25 14:10 ` Wendy Cheng
2007-04-25 15:21 ` Marc Eshel
2007-04-25 15:19 ` Wendy Cheng
2007-04-25 15:39 ` [Cluster-devel] " Wendy Cheng
2007-04-25 15:59 ` J. Bruce Fields
2007-04-25 15:52 ` Wendy Cheng
2011-11-30 10:13 ` Pavel
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=4632C5AF.7080500@redhat.com \
--to=wcheng@redhat.com \
--cc=bfields@fieldses.org \
--cc=cluster-devel@redhat.com \
--cc=frankvm@frankvm.com \
--cc=hch@infradead.org \
--cc=jlayton@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 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).