Managing token states across multiple storage processors of a data storage array

Patent metadata

Field	Value
Publication number	US-9304699-B1
Application number	US-201313929027-A
Country	US
Kind code	B1
Filing date	Jun 27, 2013
Priority date	Jun 27, 2013
Publication date	Apr 5, 2016
Grant date	Apr 5, 2016

Abstract

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.

First claim

What is claimed is:

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

Assignees

• Emc Corp

Inventors

• Goudreau Robert F
• Holt James M
• Owen Karl M
• Taylor Alan L
• Chen Chung-Huy

Classifications

• G06F3/0688 Primary

  Non-volatile semiconductor memory arrays · CPC title

• G06F3/0634

  by changing the state or mode of one or more devices · CPC title

• G06F3/0689

  Disk arrays, e.g. RAID, JBOD · CPC title

• G06F3/0617

  in relation to availability · CPC title

• G06F3/0622 Primary

  in relation to access · CPC title