+18
−40
+0
−21
Loading
nfsd does not cache the reply to a SEQUENCE. As the comment above nfsd4_replay_cache_entry() says: * The sequence operation is not cached because we can use the slot and * session values. The comment above nfsd4_cache_this() suggests otherwise. * The session reply cache only needs to cache replies that the client * actually asked us to. But it's almost free for us to cache compounds * consisting of only a SEQUENCE op, so we may as well cache those too. * Also, the protocol doesn't give us a convenient response in the case * of a replay of a solo SEQUENCE op that wasn't cached The code in nfsd4_store_cache_entry() makes it clear that only responses beyond 'cstate.data_offset' are actually cached, and data_offset is set at the end of nfsd4_encode_sequence() *after* the sequence response has been encoded. This patch simplifies code and removes the confusing comments. - nfsd4_is_solo_sequence() is discarded as not-useful. - nfsd4_cache_this() is now trivial so it too is discarded with the code placed in-line at the one call-site in nfsd4_store_cache_entry(). - nfsd4_enc_sequence_replay() is open-coded in to nfsd4_replay_cache_entry(), and then simplified to (hopefully) make the process of replaying a reply clearer. Signed-off-by:NeilBrown <neil@brown.name> Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com>