From: Frank van Maarseveen <frankvm@frankvm.com>
To: cluster-devel.redhat.com
Subject: [NFS] [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover
Date: Sat, 28 Apr 2007 12:33:50 -0000 [thread overview]
Message-ID: <20070428123332.GB3827@janus> (raw)
In-Reply-To: <17970.53957.677739.642780@notabene.brown>
On Sat, Apr 28, 2007 at 02:51:17PM +1000, Neil Brown wrote:
> On Friday April 27, wcheng at redhat.com wrote:
[...]
> Certainly a lot closer.
> If we are creating "nlm_drop_locks" and "nlm_set_grace" interfaces, we
> should spend a few moments considering exactly what semantics they
> should have.
>
> In both cases we write a filename. Presumably it must start with a
> '/' and be null terminated, so you use "echo -n" rather than "echo".
> After all, a filename can contain a newline.
I don't care much about the trailing newline. Try mounting and
exporting it and mounting it on the client ;-). Truncating the
string at the first newline may be a practical thing to do.
>
> Is there any extra info we might want to pass in or out at the same
> time?
>
> For nlm_drop_locks, we might also want to be able to query locked -
> "Do you hold any locks on this filesystem". Even "how many?".
The "no locks dropped" case might be useful. #locks dropped is
only informational (without client info) and covers the first case
too so that would be my choice but I don't have any strong opinion
about this.
>
> Does it make sense to have a single file with composite semantics?
Only if that would avoid an otherwise unavoidable race. There are
just too many components involved with NFS so to avoid any race I'd
probably unplug it temporarily with iptables or "ip addr del..."
But I would like to be able to drop locks without entering grace
mode: a zero second grace mode when combined.
>
> We write
> XX/path/name
> where XX can be:
Try mounting and exporting pathnames with spaces.. that's not going
to work anytime soon, or even anytime at all (other unixes). So no
need to use / as separator.
> a number, to set second remaining in grace period
> a '?' (or empty string) to query state
You mean: write "?/path/name" to tell the kernel what subsequent
reads should query?
> a '-' to remove all locks (and cancels any grace period)
That's a strange combination. But cancelling a grace period
is equivalent with setting it to zero seconds so no need for a
special case.
I'd go for simplicity: one file per function (unless there's an
unavoidable race). What about:
/proc/fs/nfsd/nlm_grace:
Write a number to set the grace period in seconds
(0==cancel). May be followed by a space + pathname to
indicate the superblock/list of svc_something the grace
period applies to (otherwise it's global). Truncate the
string at a newline.
/proc/fs/nfsd/nlm_unlock:
Write either a pathname or "" to drop locks. This has the
same syntax as the second field of nlm_grace.
Optional: In addition to a pathname support "fsid=" syntax in
both cases.
If you wanna go wild then support a file= syntax to recover from
stale locks on individual files due to buggy clients.
--
Frank
WARNING: multiple messages have this Message-ID (diff)
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Neil Brown <neilb@suse.de>
Cc: cluster-devel@redhat.com, Jeff Layton <jlayton@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
nfs@lists.sourceforge.net,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover
Date: Sat, 28 Apr 2007 14:33:32 +0200 [thread overview]
Message-ID: <20070428123332.GB3827@janus> (raw)
In-Reply-To: <17970.53957.677739.642780@notabene.brown>
On Sat, Apr 28, 2007 at 02:51:17PM +1000, Neil Brown wrote:
> On Friday April 27, wcheng@redhat.com wrote:
[...]
> Certainly a lot closer.
> If we are creating "nlm_drop_locks" and "nlm_set_grace" interfaces, we
> should spend a few moments considering exactly what semantics they
> should have.
>
> In both cases we write a filename. Presumably it must start with a
> '/' and be null terminated, so you use "echo -n" rather than "echo".
> After all, a filename can contain a newline.
I don't care much about the trailing newline. Try mounting and
exporting it and mounting it on the client ;-). Truncating the
string at the first newline may be a practical thing to do.
>
> Is there any extra info we might want to pass in or out at the same
> time?
>
> For nlm_drop_locks, we might also want to be able to query locked -
> "Do you hold any locks on this filesystem". Even "how many?".
The "no locks dropped" case might be useful. #locks dropped is
only informational (without client info) and covers the first case
too so that would be my choice but I don't have any strong opinion
about this.
>
> Does it make sense to have a single file with composite semantics?
Only if that would avoid an otherwise unavoidable race. There are
just too many components involved with NFS so to avoid any race I'd
probably unplug it temporarily with iptables or "ip addr del..."
But I would like to be able to drop locks without entering grace
mode: a zero second grace mode when combined.
>
> We write
> XX/path/name
> where XX can be:
Try mounting and exporting pathnames with spaces.. that's not going
to work anytime soon, or even anytime at all (other unixes). So no
need to use / as separator.
> a number, to set second remaining in grace period
> a '?' (or empty string) to query state
You mean: write "?/path/name" to tell the kernel what subsequent
reads should query?
> a '-' to remove all locks (and cancels any grace period)
That's a strange combination. But cancelling a grace period
is equivalent with setting it to zero seconds so no need for a
special case.
I'd go for simplicity: one file per function (unless there's an
unavoidable race). What about:
/proc/fs/nfsd/nlm_grace:
Write a number to set the grace period in seconds
(0==cancel). May be followed by a space + pathname to
indicate the superblock/list of svc_something the grace
period applies to (otherwise it's global). Truncate the
string at a newline.
/proc/fs/nfsd/nlm_unlock:
Write either a pathname or "" to drop locks. This has the
same syntax as the second field of nlm_grace.
Optional: In addition to a pathname support "fsid=" syntax in
both cases.
If you wanna go wild then support a file= syntax to recover from
stale locks on individual files due to buggy clients.
--
Frank
-------------------------------------------------------------------------
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 12:33 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-05 21:50 [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover Wendy Cheng
2007-04-05 21:50 ` Wendy Cheng
2007-04-11 17:01 ` [Cluster-devel] Re: [NFS] " J. Bruce Fields
2007-04-11 17:01 ` J. Bruce Fields
2007-04-17 19:30 ` [Cluster-devel] " Wendy Cheng
2007-04-17 19:30 ` Wendy Cheng
2007-04-18 18:56 ` [Cluster-devel] " Wendy Cheng
2007-04-18 18:56 ` Wendy Cheng
2007-04-18 19:46 ` [Cluster-devel] " Wendy Cheng
2007-04-18 19:46 ` Wendy Cheng
2007-04-19 14:41 ` [Cluster-devel] Re: [NFS] " Christoph Hellwig
2007-04-19 14:41 ` Christoph Hellwig
2007-04-19 15:08 ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-19 15:08 ` Wendy Cheng
[not found] ` <message from Wendy Cheng on Tuesday April 17>
2007-04-19 7:04 ` [Cluster-devel] " Neil Brown
2007-04-19 7:04 ` Neil Brown
2007-04-19 14:53 ` Wendy Cheng
2007-04-19 14:53 ` Wendy Cheng
2007-04-24 3:30 ` Wendy Cheng
2007-04-24 3:30 ` Wendy Cheng
[not found] ` <message from Wendy Cheng on Monday April 23>
2007-04-24 5:52 ` [NFS] " Neil Brown
2007-04-24 5:52 ` Neil Brown
2007-04-26 4:35 ` [NFS] " Wendy Cheng
2007-04-26 4:35 ` Wendy Cheng
[not found] ` <message from Wendy Cheng on Thursday April 26>
2007-04-26 5:43 ` [NFS] " Neil Brown
2007-04-26 5:43 ` Neil Brown
2007-04-27 2:24 ` [NFS] " Wendy Cheng
2007-04-27 2:24 ` Wendy Cheng
2007-04-27 6:00 ` [NFS] " Neil Brown
2007-04-27 6:00 ` Neil Brown
2007-04-27 11:15 ` [NFS] " Jeff Layton
2007-04-27 11:15 ` Jeff Layton
[not found] ` <message from Jeff Layton on Friday April 27>
2007-04-27 12:40 ` [NFS] " Neil Brown
2007-04-27 12:40 ` Neil Brown
2007-04-27 13:42 ` Jeff Layton
2007-04-27 18:57 ` [NFS] " Jeff Layton
2007-04-27 14:17 ` Christoph Hellwig
2007-04-27 14:17 ` Christoph Hellwig
2007-04-27 15:42 ` J. Bruce Fields
2007-04-27 15:43 ` [NFS] " J. Bruce Fields
2007-04-27 15:36 ` Wendy Cheng
2007-04-27 15:36 ` Wendy Cheng
2007-04-27 16:31 ` J. Bruce Fields
2007-04-27 16:31 ` [NFS] " J. Bruce Fields
[not found] ` <message from J. Bruce Fields on Friday April 27>
2007-04-27 22:22 ` Neil Brown
2007-04-27 22:22 ` Neil Brown
2007-04-29 20:13 ` J. Bruce Fields
2007-04-29 20:14 ` [NFS] " J. Bruce Fields
[not found] ` <message from J. Bruce Fields on Sunday April 29>
2007-04-29 23:10 ` Neil Brown
2007-04-29 23:10 ` Neil Brown
2007-04-30 5:19 ` [NFS] " Wendy Cheng
2007-04-30 5:19 ` Wendy Cheng
2007-05-04 18:42 ` [NFS] " J. Bruce Fields
2007-05-04 18:42 ` J. Bruce Fields
2007-05-04 21:35 ` [NFS] " Wendy Cheng
2007-05-04 21:35 ` Wendy Cheng
2007-04-27 20:34 ` Frank van Maarseveen
2007-04-27 20:34 ` [NFS] " Frank van Maarseveen
2007-04-28 3:55 ` Wendy Cheng
2007-04-28 3:55 ` Wendy Cheng
[not found] ` <message from Wendy Cheng on Friday April 27>
2007-04-28 4:51 ` [NFS] " Neil Brown
2007-04-28 4:51 ` Neil Brown
2007-04-28 5:26 ` Marc Eshel
2007-04-28 5:27 ` [NFS] " Marc Eshel
2007-04-28 12:33 ` Frank van Maarseveen [this message]
2007-04-28 12:33 ` Frank van Maarseveen
2007-04-27 15:12 ` Jeff Layton
2007-04-27 15:12 ` [NFS] " Jeff Layton
2007-04-25 14:18 ` [Cluster-devel] Re: [NFS] " J. Bruce Fields
2007-04-25 14:18 ` J. Bruce Fields
2007-04-25 14:10 ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-25 14:10 ` Wendy Cheng
2007-04-25 15:21 ` [Cluster-devel] Re: [NFS] " Marc Eshel
2007-04-25 15:21 ` Marc Eshel
2007-04-25 15:19 ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-25 15:19 ` Wendy Cheng
2007-04-25 15:39 ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-25 15:39 ` [Cluster-devel] " Wendy Cheng
2007-04-25 15:59 ` [Cluster-devel] Re: [NFS] " J. Bruce Fields
2007-04-25 15:59 ` J. Bruce Fields
2007-04-25 15:52 ` [Cluster-devel] Re: [NFS] " Wendy Cheng
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=20070428123332.GB3827@janus \
--to=frankvm@frankvm.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 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.