> +KNFSD4 State Object Model: > +========================== > +Written 2014 by Jeff Layton <jlayton@xxxxxxxxxxxxxxx> > + > +Introduction: > +------------- > +Until recently, knfsd relied heavily on a global mutex to ensure that objects > +didn't disappear while they were being operated on. That has proven to be a > +scalability bottleneck however, so the code has been overhauled to make heavy > +use of reference counting and spinlocks for tracking the different objects. It's hard enough to keep documents uptodate with the current version of the code, so I don't think this historical blurb buys us anything. > +struct nfs4_client: > +------------------- > +The initial object created by an NFS client using SETCLIENTID (for NFSv4.0) or > +EXCHANGE_ID (for NFSv4.1+). These objects are refcounted and timestamped. Each > +nfsd_net_ns object contains a set of these and they are tracked via short and > +long form clientid. They are hashed and searched for under the per-nfsd-net > +client_lock spinlock. > + > +The lifecycle of these is a little strange. References to it are only held > +during the processing of compounds, and in certain other operations. In their > +"resting state" they have a refcount of 0. If they are not renewed within a > +lease period, they become eligible for destruction by the laundromat. That's the normal lifecycle of objects on a lru, so I'd strike the "strange" part. > +strict nfs4_stid: > +----------------- > +A core object that represents a "generic" stateid. These are generally embedded > +within the different (more specific) stateid objects and contain fields that > +are of general use to any stateid. Maybe replace "generic" stateid with common stateid or similar? The generic_stateid term is unfortunately is used in the code in a weird way for open/lock stateids. Or better yet fix up those names in the code.. Given how documentation outside the source code gets out of data easily maybe you should move these texts to comments above each of the structures? -- 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
