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. > Agreed that there doesn't seem to be an agreed-upon way to do it now.... > > --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@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
