All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Wendy Cheng <wcheng@netapp.com>
Cc: Bob Bell
	<b_linuxnfs-Y/+76LoPTq9wBoktGHYdvgC/G2K4zDHf@public.gmane.org>,
	NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/2] NLM failover unlock
Date: Fri, 15 Feb 2008 11:20:22 -0500	[thread overview]
Message-ID: <20080215162022.GA20826@fieldses.org> (raw)
In-Reply-To: <47B490BC.2000309@netapp.com>

On Thu, Feb 14, 2008 at 02:04:28PM -0500, Wendy Cheng wrote:
> Bob Bell wrote:
>> On Mon, Jan 07, 2008 at 12:31:09AM -0500, Wendy Cheng wrote:
>>> This submission is part of the patch sets added to support NFS server 
>>> failover where the specified export is moved from one physical server 
>>> to another.
>>
>> Wendy,
>>
>> What's the current status of these patches?  I believe I have a  
>> situation that could benefit from being able to release all NLM locks  
>> on an exported filesystem.
>>
> I think Bruce has queued the unlock patch for 2.6.26 (Bruce ?) ..

Not yet, for several reasons.  First, there's two smaller problems
outstanding that I can recall:

	- We should be matching on the superblock, not the vfs mount.
	  Otherwise, for example, the unlock will have no effect if it's
	  done from a private namespace, which I think will be
	  unexpected.  Arguably this could result in revoking more locks
	  than necessary, but if the goal is to allow unmounting some
	  shared block device, then that's what we've got to do.
	- Let's get the address types right.  I think the concensus from
	  previous discussions was just to use in6_addr everywhere?

(Both those should be relatively small-let me know if you can resend
fixed versions or if you'd like me to fix them up--either's fine.)

As I've said before I'd also like to see how this will fit into a
solution for some longer-term problems:

	- How will we block locks on other nodes of a cluster filesystem
	  during grace periods/failover?
	- How will the comparable v4 references to the filesystem (from
	  opens and locks) be revoked?

I'm working on those (some patches are in

	git://linux-nfs.org/~bfields/linux.git failover

but it's still at an early stage.)  But I don't want the perfect to be
the enemy of the good, so, sure, if it looks like that's not going to be
figured out by 2.6.26 then I'll queue up this unlock patch before then.

We do need at least the small problems above fixed, though.

Also, are you planning to address the comments on the grace period
patches, or do you want me to take over revising them?

--b.

  reply	other threads:[~2008-02-15 16:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-07  5:31 [Cluster-devel] [PATCH 0/2] NLM failover unlock Wendy Cheng
2008-01-07  5:31 ` Wendy Cheng
2008-02-14 18:38 ` Bob Bell
     [not found]   ` <20080214183833.GA26936-y89O8yXFYpDSsb2jM9SCN5/hYUUxywnI@public.gmane.org>
2008-02-14 19:04     ` Wendy Cheng
2008-02-15 16:20       ` J. Bruce Fields [this message]
2008-02-15 16:30         ` Chuck Lever
2008-02-15 16:36           ` J. Bruce Fields
2008-02-15 17:25         ` Wendy Cheng

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=20080215162022.GA20826@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=b_linuxnfs-Y/+76LoPTq9wBoktGHYdvgC/G2K4zDHf@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=wcheng@netapp.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.