On Tue, Jan 24, 2012 at 06:08:55PM -0500, J. Bruce Fields wrote: > On Mon, Jan 23, 2012 at 03:01:01PM -0500, Jeff Layton wrote: > > This is the fourth iteration of this patchset. I had originally asked > > Bruce to take the last one for 3.3, but decided at the last minute to > > wait on it a bit. I knew there would be some changes needed in the > > upcall, so by waiting we can avoid needing to deal with those in code > > that has already shipped. I would like to see this patchset considered > > for 3.4 however. > > > > The previous patchset can be viewed here. That set also contains a > > more comprehensive description of the rationale for this: > > > > http://www.spinics.net/lists/linux-nfs/msg26324.html > > > > There have been a number of significant changes since the last set: > > > > - the remove/expire upcall is now gone. In a clustered environment, the > > records would need to be refcounted in order to handle that properly. That > > becomes a sticky problem when you could have nodes rebooting. We don't > > really need to remove these records individually however. Cleaning them > > out only when the grace period ends should be sufficient. > > I don't think so: > > 1. Client establishes state with server. > 2. Network goes down. > 3. A lease period passes without the client being able to renew. > The server expires the client and grants conflicting locks to > other clients. > 3. Server reboots. (Doh. Counting is hard.) --b. > 4. Network comes back up. > > At this point, the client sees that the server has rebooted and is in > its grace period, and reclaims. Ooops. > > The server needs to be able to tell the client "nope, you're not allowed > to reclaim any more" at this point. > > So we need some sort of remove/expire upcall. -- 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
