Managing token states across multiple storage processors of a data storage array
A technique manages token states across multiple storage processors (SPs) of a data storage array. The technique involves using a token, by a first SP, to identify particular data stored on the array. The technique further involves updating, by the first SP, a first SP-controlled set of token state information for the token, the first SP-controlled set of token state information including (i) a first token state which indicates whether the token is “idle” or “busy” from a perspective of the first SP and (ii) a second token state which indicates whether the token is “idle” or “busy” from a perspective of a second SP. The technique further involves expiring, by the first SP, the token in response to the first SP-controlled set of token state information indicating that the token has remained “idle” for at least a predefined amount of time.
1. A method of managing token states across multiple storage processors (SPs) of a data storage array, the method comprising:
using a token, by a first SP of the data storage array, to identify particular data stored on the data storage array;
updating, by the first SP, a first SP-controlled set of token state information for the token, the first SP-controlled set of token state information including (i) a first token state which indicates whether the token is “idle” or “busy” from a perspective of the first SP and (ii) a second token state which indicates whether the token is “idle” or “busy” from a perspective of a second SP of the data storage array; and
expiring, by the first SP, the token in response to the first SP-controlled set of token state information indicating that the token has remained “idle” for at least a predefined amount of time.
2. A method as in claim 1 , further comprising:
using the token, by the second SP, to identify the particular data stored on the data storage array; and
updating, by the second SP, a second SP-controlled set of token state information for the token, the second SP-controlled set of token state information including (i) a first token state which indicates whether the token is “idle” or “busy” from the perspective of the first SP and (ii) a second token state which indicates whether the token is “idle” or “busy” from the perspective of the second SP.
3. A method as in claim 2 wherein expiring the token by the first SP includes:
locally invalidating, by the first SP, the token from the perspective of the first SP, and
providing, by the first SP, an expiration message to the second SP, the expiration message directing the second SP to locally invalidate the token from the perspective of the second SP.
4. A method as in claim 2 wherein the data storage array includes a set of non-volatile data storage units to store host data on behalf of a set of host computers, the host data including the particular data identified using the token; and wherein the method further comprises:
performing, by the first and second SPs, host input/output (I/O) operations on the particular data in response to host I/O requests from the set of host computers.
5. A method as in claim 1 , further comprising:
receiving, by the first SP, an update message from the second SP, the update message indicating that the token is “busy” from the perspective of the second SP due to a write using token (WUT) operation initiated on the second SP, the WUT operation copying the particular data identified using the token, the first SP being constructed and arranged to update the second token state of the first SP-controlled set of token state information in response to the update message from the second SP.
6. A method as in claim 5 wherein a timing mechanism indicates an amount of time that the token has been “idle” from the perspective of the first SP to enable determination as to whether the token has remained “idle” for at least the predefined amount of time; and wherein the method further comprises:
resetting, by the first SP, the timing mechanism in response to the update message which indicates that the token is “busy” from the perspective of the second SP due to the WUT operation initiated on the second SP.
7. A method as in claim 5 , further comprising:
receiving, by the first SP, another update message from the second SP, the other update message indicating that the token is now “idle” from the perspective of the second SP due to completion of all WUT operations initiated on the second SP which copied the particular data identified using the token.
8. A method as in claim 7 wherein a timing mechanism indicates an amount of time that the token has been “idle” from the perspective of the first SP; and wherein the method further comprises:
resetting, by the first SP, the timing mechanism in response to the update message which indicates that the token is “busy” from the perspective of the second SP due to the WUT operation initiated on the second SP, and
resetting, by the first SP, the timing mechanism in response to the other update message which indicates that the token is now “idle” from the perspective of the second SP due to completion of all WUT operations initiated on the second SP which copied the particular data identified using the token.
9. A method as in claim 1 , further comprising:
providing, by the first SP, an update message to the second SP, the update message indicating that the token is “busy” from the perspective of the first SP due to a write using token (WUT) operation initiated on the first SP, the WUT operation copying the particular data identified using the token, the second SP being constructed and arranged to update a token state of a second SP-controlled set of token state information in response to the update message provided by the first SP.
10. A method as in claim 9 wherein a timing mechanism indicates an amount of time that the token has been “idle” from the perspective of the first SP to enable determination as to whether the token has remained “idle” for at least the predefined amount of time; and wherein the method further comprises:
resetting, by the first SP, the timing mechanism in response to initiating the WUT operation on the first SP.
11. A method as in claim 9 , further comprising:
providing, by the first SP, another update message to the second SP, the other update message indicating that the token is “idle” from the perspective of the first SP due to completion of all WUT operations on the first SP which copied the particular data identified using the token.
12. A method as in claim 11 wherein a timing mechanism indicates an amount of time that the token has been “idle” from the perspective of the first SP; and wherein the method further comprises:
resetting, by the first SP, the timing mechanism in response to initiating the WUT operation on the first SP, and
resetting, by the first SP, the timing mechanism in response to completing all WUT operations on the first SP which copied the particular data identified using the token.
13. A method as in claim 1 , further comprising:
maintaining a first SP-controlled write using token (WUT) counter for the token to indicate a number of WUT operations currently performed by the first SP to copy the particular data identified using the token.
14. A method as in claim 13 wherein maintaining the first SP-controlled WUT counter for the token includes:
for each new WUT operation initiated on the first SP to copy the particular data identified using the token, incrementing the first SP-controlled WUT counter for the token, and
for each WUT operation to copy the particular data identified using the token which is completed on the first SP, decrementing the first SP-controlled WUT counter for the token.
15. A method as in claim 14 wherein updating the first SP-controlled set of token state information for the token includes:
in response to decrementing the first SP-controlled WUT counter for the token to indicate that there is still at least one WUT operation ongoing on the first SP to copy the particular data identified using the token, maintaining the first token state of the first SP-controlled set of token state information to indicate that the token is still “busy” from the perspective of the first SP, and
in response to decrementing the first SP-controlled WUT counter for the token to indicate that there are no WUT operations currently on the first SP to copy the particular data identified using the token, transitioning the first token state of the first SP-controlled set of token state information to indicate that the token is now “idle” from the perspective of the first SP.
16. A method as in claim 15 , further comprising:
in response to maintaining the first token state of the first SP-controlled set of token state information to indicate that the token is still “busy” after decrementing the first SP-controlled WUT counter, not providing any update message regarding the token from the first SP to the second SP to conserve communications bandwidth between the first SP and the second SP, and
in response to transitioning the first token state of the first SP-controlled set of token state information to indicate that the token is now “idle” after decrementing the first SP-controlled WUT counter, providing an update message from the first SP to the second SP, the update message indicating that the token is now “idle” from the perspective of the first SP due to completion of all WUT operations on the first SP which copied the particular data identified using the token.
17. A storage processing apparatus, comprising:
a host interface to communicate with a set of host computers;
a storage interface to communicate with a set of non-volatile data storage units which stores host data on behalf of the set of host computers; and
control circuitry coupled to the host interface and the storage interface, the control circuitry being constructed and arranged to:
use a token to identify particular data of the host data stored on the set of non-volatile data storage units,
update a first SP-controlled set of token state information for the token, the first SP-controlled set of token state information including (i) a first token state which indicates whether the token is “idle” or “busy” from a perspective of the storage processing apparatus and (ii) a second token state which indicates whether the token is “idle” or “busy” from a perspective of another storage processing apparatus, and
expire the token in response to the first SP-controlled set of token state information indicating that the token has remained “idle” for at least a predefined amount of time.
18. A computer program product having a non-transitory computer readable medium which stores a set of instructions to manage token states across multiple storage processors (SPs) of a data storage array, the set of instructions, when carried out by a first SP of the data storage array, causing the first SP to perform a method of:
using a token to identify particular data stored on the data storage array;
updating a first SP-controlled set of token state information for the token, the first SP-controlled set of token state information including (i) a first token state which indicates whether the token is “idle” or “busy” from a perspective of the first SP and (ii) a second token state which indicates whether the token is “idle” or “busy” from a perspective of a second SP of the data storage array; and
expiring the token in response to the first SP-controlled set of token state information indicating that the token has remained “idle” for at least a predefined amount of time.