On Fri, 3 Feb 2012 14:35:33 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Feb 01, 2012 at 10:44:10AM -0500, Jeff Layton wrote: > > We'll need a way to flag the nfs4_client as already being recorded on > > stable storage so that we don't continually upcall. > > Looks like the code currently uses cl_firststate for that purpose. > > I'm perfectly open to the argument that using a u32 to store a boolean > is rather silly, and can't see any problem with doing it this way > instead, but then let's remove cl_firstate while we're at it. > > --b. > I started looking at this. The semantics on cl_firststate are a little different from my proposed flag: The meaning of the flag I was proposing is fairly clear -- I set it whenever the kernel believes that there is already a record for this client on stable storage. So, when we first upcall to check if a client is on stable storage, then we'll also set that bit if it was, as well as when we first create a client record on stable storage. The legacy tracker sets cl_firststate whenever the directory is created, or in nfs4_set_claim_prev. When the clients are restored after a reboot by reading in the contents of the v4recoverydir, then they do not have the cl_firststate set initially. It's only after a NFS4_OPEN_CLAIM_PREVIOUS open request comes in that they get it. Now, I don't think it really matters much. We'll just have this flag set a little earlier with the new client tracker, and it may get set again when it's already set. I don't see any cases right offhand where the legacy and new client trackers would cause different behavior. Am I missing any subtlety in the semantics of cl_firststate here? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
