From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v4 0/6] nfsd: overhaul the client name tracking code
Date: Wed, 25 Jan 2012 17:11:49 -0500 [thread overview]
Message-ID: <20120125221149.GC22216@fieldses.org> (raw)
In-Reply-To: <C2D8B860-6B9F-4187-B9DE-9BF52C8398B0@oracle.com>
On Wed, Jan 25, 2012 at 04:55:54PM -0500, Chuck Lever wrote:
>
> On Jan 25, 2012, at 4:54 PM, J. Bruce Fields wrote:
>
> > On Wed, Jan 25, 2012 at 04:29:02PM -0500, Chuck Lever wrote:
> >>
> >> On Jan 25, 2012, at 4:25 PM, J. Bruce Fields wrote:
> >>
> >>> On Wed, Jan 25, 2012 at 03:23:56PM -0500, Jeff Layton wrote:
> >>>> I suggest that we only allow the reclaim of locks
> >>>> on the original address against which they were established.
> >>>
> >>> I'm not sure what that means.
> >>>
> >>> If a server stops responding, the v4.0 client has two choices: it can
> >>> either wait for the server to come back, and reclaim when it does. Or
> >>> if it supports failover it can go find another server and perform
> >>> reclaims over there.
> >>
> >> Honestly, I don't think that's possible in NFSv4.0.
> >
> > Well, it was *supposed* to be possible, wasn't it? I thought fixing up
> > 3530 to make that work was part of what the discussion around
> > http://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-migration-issues/
> > was about? (OK, I should actually read that.)
>
> No, that's just for migration. Failover is different, though it uses some of the same mechanisms.
Hm, I would've thought once you've worked out the clientid, then
failover would look pretty similar in 4.0 and 4.1.
And I don't think the richer locations info helps e.g. with the server
trying to track client-reclaimability across reboots and failovers.
--b.
> >> The richer information provided by fs_locations_info can allow the client to determine whether two servers share more than simply data. That information does not exist in NFSv4.0, so there's no way a client can expect that two servers lists in fs_locations results will always have the same NFSv4 state.
> >>
> >> Thus I believe that NFSv4.0 replication is limited to read-only data. But I have to go back and read that chapter of 3530 again.
> >>
> >>> I'm a little unclear how it does that, but I suppose it first tests
> >>> somehow to see whether its existing state is supported, and if not, it
> >>> establishes a new clientid with SETCLIENTID/SETCILENTID_CONFIRM using
> >>> its old name, and then attempts to reclaim.
> >>>
> >>> You're now requiring it *not* to do that if it happens that the servers
> >>> all rebooted in the meantime. How does it know that that's what
> >>> happened?
> >>>
> >>> Or maybe that's not what you want to require, I'm not sure.
> >>>
> >>> --b.
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >> --
> >> Chuck Lever
> >> chuck[dot]lever[at]oracle[dot]com
> >>
> >>
> >>
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
next prev parent reply other threads:[~2012-01-25 22:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 20:01 [PATCH v4 0/6] nfsd: overhaul the client name tracking code Jeff Layton
2012-01-23 20:01 ` [PATCH v4 1/6] nfsd: add nfsd4_client_tracking_ops struct and a way to set it Jeff Layton
2012-01-23 20:01 ` [PATCH v4 2/6] sunrpc: create nfsd dir in rpc_pipefs Jeff Layton
2012-01-23 20:01 ` [PATCH v4 3/6] nfsd: convert nfs4_client->cl_cb_flags to a generic flags field Jeff Layton
2012-01-23 20:01 ` [PATCH v4 4/6] nfsd: add a header describing upcall to nfsdcld Jeff Layton
2012-01-23 20:01 ` [PATCH v4 5/6] nfsd: add the infrastructure to handle the cld upcall Jeff Layton
2012-01-23 20:01 ` [PATCH v4 6/6] nfsd: get boot generation number from upcall instead of boot_time Jeff Layton
2012-01-24 23:08 ` [PATCH v4 0/6] nfsd: overhaul the client name tracking code J. Bruce Fields
2012-01-24 23:11 ` J. Bruce Fields
2012-01-25 11:41 ` Jeff Layton
2012-01-25 13:11 ` J. Bruce Fields
2012-01-25 13:38 ` Jeff Layton
2012-01-25 16:47 ` Chuck Lever
2012-01-25 17:14 ` J. Bruce Fields
2012-01-25 17:41 ` Chuck Lever
2012-01-25 18:55 ` J. Bruce Fields
2012-01-25 20:23 ` Jeff Layton
2012-01-25 21:25 ` J. Bruce Fields
2012-01-25 21:29 ` Chuck Lever
2012-01-25 21:54 ` J. Bruce Fields
2012-01-25 21:55 ` Chuck Lever
2012-01-25 22:11 ` J. Bruce Fields [this message]
2012-01-27 15:43 ` Jeff Layton
2012-01-25 20:29 ` Chuck Lever
2012-01-25 20:53 ` J. Bruce Fields
2012-01-25 21:08 ` Chuck Lever
2012-01-25 19:08 ` Jeff Layton
2012-01-24 23:10 ` J. Bruce Fields
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=20120125221149.GC22216@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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.