On Tue, Sep 01, 2015 at 10:48:27AM -0400, Andrew W Elble wrote: > > I should probably state what I'm currently chasing: > > 1.) Somehow, delegations wind up on the cl_revoked list at the server. > 2.) The server continually asserts SEQ4_STATUS_RECALLABLE_STATE_REVOKED. > 3.) The client for some reason doesn't have anything to give the server > to satisfy it. > > I speculate that this patch will assist in making this go away - I'm > just not 100% sure of all the conditions that result in making #1 possible. > (Enough recalls backed up on the callback slot on the same filehandle > stacking timeouts/retries and resultant path down errors to exceed lease > time?). Even in the worst case where the client never gets the recall, in theory it should take the RECALLABLE_STATE_REVOKED as a sign that it's missed one and return its delegations. Is the client attempting any such recovery when it sees that flag? > Unfortunately this problem seems to always occur at ~1AM - and > obtaining a network capture of the problem in action has been elusive. Anyway, sounds interesting, let us know what you find.... --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
