From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from fieldses.org ([174.143.236.118]:39573 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750873Ab2AYWLw (ORCPT ); Wed, 25 Jan 2012 17:11:52 -0500 Date: Wed, 25 Jan 2012 17:11:49 -0500 From: "J. Bruce Fields" To: Chuck Lever Cc: Jeff Layton , linux-nfs@vger.kernel.org Subject: Re: [PATCH v4 0/6] nfsd: overhaul the client name tracking code Message-ID: <20120125221149.GC22216@fieldses.org> References: <20120125083820.637c8362@tlielax.poochiereds.net> <20120125171401.GI17873@fieldses.org> <20120125185529.GJ17873@fieldses.org> <20120125152356.10bdd772@tlielax.poochiereds.net> <20120125212553.GA22216@fieldses.org> <20120125215415.GB22216@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: 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 > > > >