Secure data access after storage failure

Abstract

Relates to secure data access after a storage failure. Request identifiers are employed with various systems and methods to enable an application to suspend execution during a failure and subsequently resume execution and communication with a storage system once the failure is resolved. An application residing on a node may attempt to access target data on the storage system. The application sends a request to access the target data. The request may be associated with a request identifier that identifies the application. When the storage system experiences a failure, the application receives a failure notification. As a result of the notification, the application suspends execution. When the node reestablishes a connection to the storage system, the application resumes execution using the same request identifier. If the resume request is granted, the application is guaranteed that the target data was not modified during the failure.

Description

[0001] This application is a divisional application of the Chinese invention patent application with international application number PCT / US2015 / 042555, international application date July 29, 2015, entering the Chinese national phase on March 27, 2017, national application number 201580052237.7, and invention name “Secure Data Access after Storage Failure”. Technical Field

[0002] The present application relates generally to the field of computers, and more particularly to systems and methods for secure data access after a storage failure. Background Art

[0003] Clustered environments (e.g., environments where workloads are distributed across multiple machines) are commonly used to provide failover and high information availability to clients. Clustered environments allow clients to access resources via one or more nodes that are part of the environment. Clustered environments can act as clients, servers, or both. In a client cluster server, an application can reside on any of the nodes that make up the cluster. An application can issue an access request to target data stored by a storage system. If an error occurs during an access request, the application may experience a delay that affects execution.

[0004] Examples are made with respect to these and other considerations. Furthermore, while relatively specific problems are discussed, it should be understood that these examples should not be limited to solving the specific problems identified in the background. Summary of the invention

[0005] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description section. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0006] Systems and methods are disclosed herein that enable applications to suspend execution during a failure and subsequently resume execution and communication with a storage system once the failure is resolved. According to some aspects, an application residing on a node in a client cluster sends an access request to a node in a server cluster to access target data. In an example, a request identifier is used to identify an application and / or related workload requesting a resource. The request identifier can be provided with the request. When a client accesses the target data, the request identifier is stored in a persistent storage device and associated with the requested target data.

[0007] Before the application completes its operation on the target data, a failure may occur, which causes the application to lose communication with the storage system. For example, a server in the storage system may be restarted, a related file system may be dismounted, a communication link may fail, and so on. In such a case, the access request issued by the application to the target data stored by the storage system will experience a delay or fail completely. However, even if the application's lock on the target data expires during the failure, the stored identifier may not be deleted from the persistent storage device. During the failure, the application can receive a notification that it has lost communication with the storage system and can suspend execution. When reestablishing communication with the storage system, the application can receive a resolution notification and attempt to resume execution. Further, the application can send a recovery request to the storage system to regain access to the target data. The recovery request may include or reference a request identifier. The request identifier allows the storage system that manages the request to determine that the recovery request belongs to the same application that has previously accessed the resource. Doing so allows the server to grant the application's recovery request for access to the target data. In the event that the target data was modified prior to the restore request, the storage system disassociates the request identifier from the target data (e.g., by deleting the stored identifier from persistent storage) so that the application may not be able to restore its previous communication with the storage system. As a result, the application is assured that if it is able to reestablish communication using the restore request and the original request identifier, the target data has not been modified since the communication failure. Otherwise, the application is alerted that the target data has changed, and the application can make a decision whether to take other action.

[0008] Examples may be implemented as a computer process, a computing system, or as an article of manufacture, such as a computer program product or a computer readable medium. A computer program product may be a computer storage medium that is readable by a computer system and encodes a computer program of instructions for executing a computer process. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Non-limiting and non-exhaustive examples are described with reference to the following figures.

[0010] Figure 1 A system is illustrated that may be used to implement the examples described herein.

[0011] Figure 2 A system is illustrated that may be used to implement the examples described herein.

[0012] Figure 3 It is the operational process of the application communicating with the storage system.

[0013] Figure 4 It is the operation process of the storage system that communicates with the application.

[0014] Figure 5is a block diagram illustrating an example of a computing device with which aspects of the invention may be practiced.

[0015] Fig. 6A and Figure 6B is a simplified block diagram of a mobile computing device with which aspects of the invention may be practiced.

[0016] Figure 7 is a simplified block diagram of a distributed computing system in which aspects of the invention may be practiced. DETAILED DESCRIPTION

[0017] Various aspects are described more fully below with reference to the accompanying drawings, which form a part thereof and show specific exemplary aspects. However, examples can be implemented in many different forms and should not be construed as being limited to the examples set forth herein. Therefore, examples can take the form of hardware implementations, or software implementations as a whole, or combined software and hardware implementations. The following detailed description is therefore not taken in a restrictive sense.

[0018] Examples of the present disclosure relate to providing applications with a mechanism for reliably accessing target data on a storage system and handling communication failures. In an example, the storage system may be a local device, a network attached storage device, a distributed file server, or any other type of storage system in a computing environment. The target data may reside on a standalone server, or it may reside in a clustered environment. In the examples disclosed herein, the clustered environment may include one or more nodes (e.g., client and / or server devices).

[0019] In one example, an application may request access to target data. The target data may be stored locally (e.g., on a client node), in a remote device (e.g., a different node in a client clustering environment or a remote server), or in a clustered environment different from the client clustering environment (e.g., an environment containing multiple nodes). For example, in an example where the clustered environment may be a client or server cluster, those skilled in the art will appreciate that the systems and methods disclosed herein may be employed in any other type of environment (such as, but not limited to, a virtual network).

[0020] Data can be shared between multiple requestors. As used herein, a requestor can include any application, workload, thread, or other process or entity requesting access to target data. Although the examples described herein can be described with respect to the "application" or "client" or "process" or "workload" acting as a requestor, the present disclosure is not so limited. When a requestor accesses target data, the target data can be locked, thereby prohibiting other requestors from accessing it until the lock is released. Locking target data can be used to prevent conflicts-that is, to prevent modification of target data by another requestor before the requestor performing the access has performed its operation. Typically, when the lock is released, the storage system no longer retains any association between the target data and the requestor.

[0021] In some instances, when a failure occurs that affects the requester's communication with the storage system, the requester may be unable to reconnect to the storage system before the lock on the target data is released. As a result, the requester becomes disassociated from the target data. For example, if the storage system maintains a lock using a workload instance identifier proposed or referenced by the requester in an access request, the workload instance identifier can typically be deleted and / or disassociated from the target data when the lock is released. Further, because the lock is released, when establishing a new connection, the requester cannot assume that the target data has not been modified since it was last accessed by the requester. Therefore, instead of resuming execution and communication with the storage system, the requester must establish a new communication session and assume that the target data is in an unknown state.

[0022] Further, when a requester is communicating with a storage system, the requester may expect not to receive an indication of a communication delay or failure, and may instead assume that its contract with the storage system (and / or the input / output (IO) manager on the client hosting the requester) guarantees that access requests will be retried until they succeed. As a result, a communication failure will cause the requester to continue waiting for a response from the storage system. This may affect the behavior of the requester and cause execution delays. For example, the requester may be "frozen" and unable to perform any processing until the failure is resolved. The systems and methods disclosed herein provide mechanisms for identifying situations in which a requester is attempting to resume communication with a storage system, and mechanisms for notifying the requester of communication delays or failures, thereby mitigating the impact on execution and enabling the requester to resume execution and communication after a failure.

[0023] Figure 1A system 100 is illustrated that can be used to implement some examples. The system 100 includes a client 102 and a storage system 108. In the illustrated example, the client 102 includes a requestor, such as an application 104 hosted by a physical or virtual computing device, and an input / output (IO) manager 106. The IO manager 106 relays and manages communications between the application 104 and the storage system 108. The storage system 108 stores information accessed by the application 104. Although in Figure 1 In the example, only the application 104 on the client 102 is shown as communicating with the storage system 108, but in other examples, there may be more than one application and more than one client accessing information from the storage system 108. In some examples, the storage system 108 may include a storage device locally connected to the client 102, a storage device remote from the client 102 accessible over a network, or a storage device shared among clustered file servers.

[0024] According to one example, the storage system 108 is used to provide consistent availability to the application 104. This is accomplished by utilizing components on the client 102 and the storage system 108 to store information that can be used to reestablish communications between the client 102 and the storage system 108 if there is a communications failure, file system unmount, reboot, or any other type of failure.

[0025] As described in more detail below, the stored information and communication failure notifications allow the client 102 to have consistent file access and enable applications running on the client 102 to handle communication failures that may occur. In an example, the client 102 can communicate with the storage system 108 using the Server Message Block (SMB) 2.0 / 3.0 protocol.

[0026] To illustrate an example, application 104 may indicate to IO manager 106 that a communication failure during a communication session with storage system 108 should be reported. In some examples, the indication may specify a specified time period to wait for a request to succeed, after which the request should be reported as having failed. In examples lacking such an indication, application 104 may rely on IO manager 106 to retry access requests to storage system 108. This may cause application 104 to wait indefinitely without information about the nature or length of the delay.

[0027] Application 104 may send an access request to target data to storage system 108. The access request to target data may include multiple file operations to be performed on the target data. These operations may be, for example, opening to read / write data, listing properties, leasing requests to allow data to be cached locally, or other file access operations. In some examples, the access request may include or reference a request identifier, such as a workload instance identifier.

[0028] The storage system 108 receives a request for access to the target data. In some examples, the storage system 108 can determine whether the target data is locked and therefore associated with a different request identifier (e.g., for a different requestor), such as the client 102 or another application running on a different client. If the target data is locked, the storage system 108 can deny the file access request, can break the lock, or can take other actions depending on the protocol employed.

[0029] When determining that the access request should be granted, the storage system 108 sends a response granting access to the target data to the client 102. The request identifier may be stored in a persistent storage device by the storage system 108. When the request identifier is stored by the storage system 108, it may be referred to as a stored identifier in this article. In some examples, the target data may be locked before or after granting the access request. In some examples, the lock may be configured to be released when all operations in the request are completed (thus allowing other requesters to have access to the target data). Further, the lock may expire after a specified time period or expire when the shorter of the specified time period and the time when all operations in the request are completed. In other examples, the lock may provide exclusive access to the client of the target data until the client releases the lock or until an event that breaks the lock occurs. For example, in accordance with the SMB protocol, a unique OpLock from the storage system 108 may be provided to the client 102. The client 102 may assume that it is the only process with access to the target data, and the client 102 may cache all changes before delivering the changes to the target data to the storage system 108. If another client / process attempts to open the same target data, the storage system 108 sends a message (called a break or revocation) to the client 102 that invalidates the exclusive OpLock previously given to the client 102. The client 102 then clears all changes to the target data and sends them to the storage system 108.

[0030] At some point, the client 102 may experience a communication failure with the storage system 108. The failure may be caused by disconnection, unmounting of the file system, or restart in some examples. As a result of the communication failure, the IO manager 106 provides a notification of the failure to the application 104. In an example, such a notification occurs only when the application 104 has "opted in" and provides the following indication to the IO manager 106: the application 104 will be notified in the event of a communication failure with the storage system 108. In an example, the notification of the failure may include additional failure information describing the nature and / or expected length of the failure. The application 104 may use the additional failure information to determine what action to take, including continuing to wait, abandoning a specific request, retrying the request, restarting the application 104, and the like. In addition to other options, upon receiving the notification, the application 104 may also suspend execution. In other examples, the application 104 may also (or alternatively) suspend IO operations or related processing. In an example, the failure may also cause the storage system 108 to release the application 104's lock on the target data, or the lock may expire during the failure.

[0031] Finally, the failure may be resolved, and the connection between the client 102 and the storage system 108 may be reestablished. The IO manager 106 determines whether the failure has been resolved, and if so, provides a resolution notification to the application 104. In an example, the application 104 may also determine whether the failure has been resolved, for example, by retrying the access request. After receiving the resolution notification, the application 104 may resume execution. In some examples where only IO operations are suspended, the application 104 may also resume IO operations or related processing. The application 104 sends a resume request to resume communication with the storage system 108 for target data. In an example, the resume request may be sent by or through the IO manager 106. The resume request may include an access request that includes (or references) a request identifier used before the failure, and may include a flag indicating to the storage system that the access request is a resume request. The storage system 108 receives the resume request. The storage system 108 determines whether the target data has changed since the failure. The determination of whether the target data has changed may also be made in part before receiving the resume request.

[0032] If the storage system 108 determines that the target data has not changed, the storage system 108 grants the recovery request. In the example, the storage system 108 determines whether the target data has changed by comparing the request identifier in the recovery request with the stored identifier, which is from the client's most recent access request to the target data. If another process or application changes the target data between the time of the failure and the time of the recovery request, the storage system 108 will have deleted the stored identifier from the most recent access request of the client 102. In this way, if the stored identifier matches the identifier included in the recovery request or otherwise associated with the recovery request, the storage system grants the recovery request. Granting the recovery request effectively guarantees to the application that the target data has not changed since the access request for which the stored identifier was initially stored. Therefore, the client 102 is confident of data integrity when continuing its previous operation. For example, if the client 102 has cached writes to the target data that were not completed before the failure, these writes can now be completed. If storage system 108 determines that the target data has changed (e.g., the request identifier in the restore request does not match the identifier stored in persistent storage), storage system 108 rejects the restore request. As used herein, a "match" need not include an exact copy. Rather, a match of identifiers requires only that the entity comparing the identifiers is sufficiently satisfied that the two identifiers refer to the same request and / or requestor at a given level of specificity.

[0033] In an example, the client 102 may be hosting one or more virtual machines using one or more virtual hard drives on the storage system 108. When the storage system 108 fails, the reliability layer (such as SMB continuous availability) may abandon the attempt to recover. This causes the application 104 to receive IO failures, which effectively "freeze" the virtual machine with the target data opened on the storage system 108. Typically, the virtual machine is required to go through a restart process to handle the failure. However, the present disclosure allows the virtual machine to be suspended and resumed once the failure is resolved. In this way, the operating system restart within the virtual machine can be avoided. However, in order to accomplish this, data integrity must be maintained.

[0034] When a virtual machine is suspended, all processing on the storage system 108 for the virtual machine may be turned off, but the operating system state within the virtual machine may be saved. For example, the New Technology File System (NTFS) installed on the virtual hard drive makes the following assumption: upon resumption of the virtual machine, all the contents of the virtual hard drive are the same. If the contents of the virtual hard drive change while the virtual machine is suspended, the virtual hard drive may be damaged. The present disclosure makes it possible to efficiently determine whether it is the same when resuming a virtual machine after it has been suspended.

[0035] The above description is only Figure 1 An example of how the examples shown in the example can operate. As described in more detail below, the examples may involve different steps or operations. These can be implemented using any appropriate software or hardware components or modules.

[0036] Figure 2 A system 200 is illustrated that can be used to implement some examples. System 200 includes nodes 202 and 208. Node 202 includes an application 204 and an IO manager 206 hosted by a physical or virtual computing device. Application 204 can be a virtualized application. Node 208 includes other utilities 210 and may also include one or more applications and IO managers (not shown). Nodes 202 and 208 can be part of a client cluster of physical and / or virtual computing devices. Nodes 202 and 208 communicate with storage system 214 via network 212 using, for example, the SMB protocol. Storage system 214 stores information accessed by one or more applications on nodes 202 and 208. In an example, nodes 202 and 208 can be considered requestors as described herein. Nodes 202 and 208 establish a connection with storage system 214 to access information from scalable file server 216. Although in Figure 2 Only nodes 202 and 208 are shown in communication with storage system 214 , but in other examples there may be more (or less than) two clients accessing information from storage system 214 .

[0037] like Figure 2, the storage system 214 includes nodes 214A and 214B, which provide both high availability and redundancy for a scalable file server 216. In an example, the storage system 214 provides a scalable file server 216 accessed by clients 202 and 208. The scalable file server 216 may include multiple clustered servers that can collaborate to provide file information from a distributed file system 218. The distributed file system 218 includes file information stored on a physical storage device 226. The file system 222 of the physical storage device 226 is installed on the node 214B. In some examples, the format of the file system 222 may be a new technology file system (NTFS) or a resilient file system (ReFS). The node 214B acts as a coordinator of the distributed file system 218 and relays file operations from the distributed file system 218 to the file system 222, such as read, write, and metadata operations. In some examples, node 214A may perform file operations directly on physical storage 226, but node 214B may have exclusive write access such that write requests are forwarded by node 214A to node 214B rather than being sent directly to physical storage 226. Additionally, request identifier filter 220 associates access requests with identifiers that are then stored in persistent storage 224. For example, persistent storage 224 may include a recovery key filter database that is utilized by a recovery key filter attached to an NTFS file system. Although Figure 2 Two nodes are shown in FIG. 2 , but in other examples, storage system 214 may include more than two nodes or less than two nodes.

[0038] According to an example, nodes 214A and 214B are used to provide consistent availability of scalable file server 216. This is accomplished by utilizing components on nodes 202, 208, 214A, and 214B to store information that can be used to reestablish communications between applications on nodes 202 and 208 and scalable file server 216 on nodes 214A and 214B if there is a failure (such as a failure of network 212, a removal of distributed file system 218 or file system 222, or a failure or restart of one of nodes 214A and 214B). Further, application 204 can indicate to IO manager 206 that application 204 is notified of failures that affect communication with storage system 214. As described in more detail below, the stored information and communication failure notifications allow nodes 202 and 208 to have consistent file access and enable applications running on nodes 202 and 208 to handle communication failures that may occur.

[0039] Each node (e.g., 214A and 214B) in the example provides access to file data for a client and is configured to provide consistent availability of file data to the client. To illustrate an example, application 204 may indicate to IO manager 206 that a failure during a communication session with storage system 214 should be reported to application 204. In the example, the application may have to "opt in" to receive an indication of a failure. In some examples, the indication may specify a time period to wait for the request to succeed, after which the request should be reported as having failed. Application 204 may send an access request to target data to node 214A. The access request may be associated with or include a request identifier (such as a workload instance identifier). For example, when a new workload is started, a tuple may be created that includes: <workload placement Id, workload Id, workload instance Id>. The access request to target data may include multiple file operations to be performed on the target data. These operations may, for example, be open to read / write data, enumerate attributes, lease requests to allow data to be cached locally, or other file access operations. In an example, the requested target data may include a virtual hard drive image including a guest virtual machine.

[0040] Node 214A receives the access request to the target data. In some examples, scalable file server 216 can determine whether the target data is locked (e.g., being accessed by a different application or process). If the target data is locked, scalable file server 216 can deny the file access request or take other actions specified by the specific protocol used.

[0041] Upon determining that the request should be granted, node 214A sends a response to node 202 granting access to the target data. Request identifier filter 220 stores the request identifier included in or associated with the access request from node 202 in persistent storage 224. In some examples, the target data may then be locked. The lock on the target data may eventually be released (e.g., due to a failure) before all operations from application 204 have been completed, but the stored identifier may continue to be retained by persistent storage 224. Further, the lock may expire after a specified period of time.

[0042] At some point, node 202 may experience a communication failure with storage system 214. The failure may be caused by, for example, a disconnect, a removal of a file system, or a restart. As a result of the communication failure, IO manager 206 provides notification of the failure to application 204. Upon receiving the notification, application 204 may suspend execution of one or more guest virtual machines. In addition to suspending a guest virtual machine or in lieu of suspending a guest virtual machine, application 204 may also suspend IO operations or related processing.

[0043] Finally, the connection between node 202 and storage system 214 may be restored. When IO manager 206 determines that the fault has been resolved, it provides a solution notification to application 204. In the example, application 204 can determine that the fault has been resolved by other methods. After receiving the solution notification, application 204 can resume execution, including resuming the execution of one or more guest virtual machines. In the example, application 204 can also resume IO operations or related processing. Application 204 sends a recovery request to resume communication with storage system 214 and seek access to target data. The recovery request from application 204 includes or is associated with a recovery request identifier, which can be the same identifier used in the first access request before the failure. In addition, the recovery request can include a mark indicating to storage system 214 that the request is a recovery request. In this example, node 214B receives the recovery request, and node 214B determines whether the target data has changed since the failure.

[0044] If node 214B determines that the target data has not changed, node 214B grants the restore request and provides access to the target data to application 204. In some examples and as further explained below, the determination that the target data has not changed since the previous access request of application 204 can be made by determining that the identifier included by (or associated with) the restore request continues to be stored in (and has not been deleted from) persistent storage 224. When the restore request is granted, application 204 and node 214B can complete any operations that were interrupted and not completed before the failure. When the restore request is granted, the target data can be locked again by node 214B on behalf of application 204. Finally, the lock on the target data can be released again (e.g., due to another failure, completion of the operation performed by application 204, etc.), but the stored identifier can continue to be retained by persistent storage 224. Further, the lock may expire after a specified time period.

[0045] In some examples, node 214B may determine that the target data has changed between the most recent access request of application 204 and the recovery request. For example, at some point, other utilities 210 on node 208 may change the target data before application 204 on node 202 reestablishes its connection to storage system 214. This may occur, for example, in the following situation: application 204 has a lock on the target data as a result of its most recent access request; however, the lock expires or is released after the failure occurs, but before all operations of application 204 on the target data are completed. The termination of the lock may allow the other utility 210 to change the target data before the recovery request is received from application 204. If the target data has changed, node 214B can remove the request identifier from persistent storage 224. In an example, the stored identifier of the most recent access request from application 204 to the target data can be deleted from persistent storage when the other utility 210 changes the target data (even before the recovery request occurs). For example, the storage system 214 may continuously or periodically monitor changes to the target data (for which the storage system 214 currently stores stored identifiers in the persistent storage 224), and delete such stored identifiers when changes are made. In this case, the determination of whether the target data has changed requires simply checking whether the identifier included in (or associated with) the restore request matches the stored identifier for the target data in the persistent storage 224. In an example, operations that do not constitute changes or alterations to the target data may include read, deflating, compression, deduplication, or snapshot operations, and such operations on behalf of another application or other utility 210 will not cause the stored identifier for the target data of the application 204 to be deleted from the persistent storage 224. If the target data has changed, the storage system 214 may deny the restore request, and the application may take further action. For example, if the virtual machine has been suspended during a failure and a restore request after the failure is denied by the storage system 214, the operating system within the virtual machine may be suspended again, at which time a determination to restart the virtual machine may be made.

[0046] As can be appreciated, the above description of system 200 is not intended to limit the examples described herein. Figure 2 The description thereof is intended only to illustrate some example implementations. In other examples, different types of information may be stored on different components in the system 200. Thus, the examples are not limited to Figure 2 Things shown and described in.

[0047] Figure 3 and Figure 4The operation flow 300 and 400 according to the example are illustrated. The operation flow 300 and 400 can be executed in any suitable computing environment. For example, these operation flows can be executed by such as Figure 1 and Figure 2 Therefore, the description of the operation flow 300 and 400 can refer to Figure 1 and Figure 2 However, it will be understood that Figure 1 and Figure 2 The embodiments are non-limiting environments for operating processes 300 and 400.

[0048] Furthermore, although the operation flows 300 and 400 are illustrated and described sequentially in a particular order, in other examples, the operations may be performed in a different order, multiple times, and / or in parallel. Further, one or more operations may be omitted or combined in some examples. In addition, it should be understood that ordinals (such as "first") are not intended to imply a sequence or order unless otherwise specified, and are used to distinguish between similar elements. For example, a "first access request" need not be an initial access request, but should be interpreted as being different from a "second access request" or a "recovery request."

[0049] Operational flow 300 illustrates operations for an application communicating with a storage system. In an example, Figure 3 The process 300 shown in FIG. 3 may be executed by an application running on a client, for example, application 204 ( Figure 2 ).

[0050] Flow 300 begins at operation 302, where an indication that a storage system failure should be reported to an application is communicated. This indication may be made to an IO manager, such as IO manager 206 ( Figure 2 ). In some examples, the indication may specify a specified time period to wait for the access request to succeed, after which the access request should be reported as having failed.

[0051] The process flows from operation 302 to operation 304, where a first access request to target data is sent. The first access request is associated with a first identifier. In some examples, the first identifier may be included as part of the first access request. The access request to the target data may include a plurality of file operations to be performed on the target data. These operations may be, for example, opening to read / write data, enumerating properties, leasing requests to allow local caching of data, or other file access operations.

[0052] At operation 306, a response granting access to the requested target data is received. Moving to operation 308, a notification of a first failure is received. The failure may be caused by, for example, a communication failure, a file system unmount, or a restart. Process 300 then moves to operation 310, where a determination is made to suspend the application after receiving the failure notification. In other examples, operation 310 may also include suspending IO operations and related processing. For example, application 204 may suspend a guest virtual machine ( Figure 2 ). In some examples, the fault notification may include an indication of whether the fault is expected to be resolved within a specific time period. This information allows the application to decide whether to suspend IO operations, restart, or take other actions.

[0053] At operation 312, an indication that the first fault has been resolved is received. Moving to operation 314, the application is resumed. In other examples, operation 314 may also include resuming IO operations and related processing. For example, application 204 may resume the guest virtual machine ( Figure 2 ). In an example, operation 314 may proceed without first receiving an indication that the fault has been resolved.

[0054] The process 300 then moves to operation 316, where a recovery request for the target data is sent. The recovery request is associated with the first identifier and includes an indication (such as a tag) that the request is a recovery request. In some examples, the first identifier may be included as part of the recovery request. After operation 316, the process 300 moves to operation 318, where it is determined whether the recovery request is granted. If the recovery request is granted, a response granting access to the requested target data is received 320. The application that receives the response granting the recovery request may consider the grant of the request as a confirmation that the target data has not changed between the application's most recent access request to the target data and the recovery request. The application may then continue any unfinished operations on the target data. If the recovery request is rejected, further action is taken 322. For example, the application that receives the rejection of the recovery request may choose to restart. In an example, the application may also provide an indication of the failure to the user through a user interface and provide the user with the option of taking further action.

[0055] Operational flow 400 illustrates steps for a storage system communicating with an application. In an example, flow 400 may be performed by a storage system, such as one or more file servers, for example, node 214A and / or node 214B ( Figure 2 ).

[0056] Process 400 begins at operation 402, where a first access request to target data is received. The first access request is associated with a request identifier. In some examples, the request identifier may be included as part of the first access request. The access request to the target data may include a plurality of file operations to be performed on the target data. These operations may be, for example, open to read / write data, enumerate properties, lease requests to allow local caching of data, or other file access operations. After operation 402, process 400 proceeds to decision 404, where a decision is made as to whether the target data is locked.

[0057] If it is determined at decision 404 that the target data is locked, then the flow proceeds to operation 406 where the first access request is denied. In other examples, operation 406 may include breaking the lock, in which case the flow proceeds to operation 408.

[0058] If it is determined at decision 404 that the target data is not locked, then flow continues to operation 408 where a lock is set on the target data for the requestor. The lock may expire after a specified period of time, or may be terminated according to a specific protocol. Moving to operation 410, access to the requested target data is granted. Flow then continues to operation 412 where the request identifier is stored in persistent storage.

[0059] The process flows to operation 414, where a failure occurs. The failure may result from, for example, a connection interruption, a removal of a file system associated with the storage system, or a restart of the storage system, among others. In the example, the process 400 includes an operation 416, where the lock created at operation 408 is released and the request identifier is retained in the persistent storage device. For example, the requester may not have completed all operations on the target data before the failure; however, the lock is released due to the expiration of the time period, due to the failure itself, or due to other factors. The process then continues to decision 418, where a decision is made as to whether the target data has been modified since it was last accessed at operation 410.

[0060] If it is determined at decision 418 that the target data is modified, flow passes to operation 420 where the stored request identifier is removed from persistent storage. For example, if the target data is changed by another process after the lock is released in operation 416, the stored identifier associating the target data with the requestor may be deleted from persistent storage.

[0061] Flow 400 then continues (from decision operation 418 or operation 420) to operation 422, where a resume request is received. The resume request is associated with a resume request identifier, which may be the same as the request identifier received in operation 402. In some examples, the resume request identifier may be included as part of the resume request. Further, in examples, decision 418 may occur after the resume request is received. After operation 422, flow 400 moves to decision 424, where a determination is made whether the request identifier matches an identifier stored in persistent storage.

[0062] If, at decision 424, it is determined that the request identifiers do not match, flow moves to operation 426 where the restore request is denied.

[0063] If it is determined at decision 424 that the request identifier matches, then in some examples, the process continues to operation 428, where a lock is set on the target data for the requestor. The lock may expire after a specified period of time, or may be terminated according to a specific protocol. Moving to operation 430, access to the requested target data is granted. In other examples, the process 400 includes operation 432, where the lock created at operation 428 is finally released and the request identifier is retained in the persistent storage device. After operation 430 (or operation 432 in other examples), the operational flow ends.

[0064] Figure 5-Figure 7 The and associated descriptions provide a discussion of various operating environments in which examples of the invention may be practiced. Figure 5-Figure 7 The devices and systems illustrated and discussed are for purposes of example and description and are not limitations of the wide variety of computing device configurations that may be used to practice the examples of the invention described herein.

[0065] Figure 5is a block diagram illustrating the physical components of a computing device 502 (e.g., nodes 202, 208, 214A, and 214B) with which examples of the present disclosure may be practiced. The computing device components described below may be suitable for the computing device described above. In a basic configuration, the computing device 502 may include at least one processing unit 504 and a system memory 506. Depending on the configuration and type of the computing device, the system memory 506 may include, but is not limited to, volatile storage devices (e.g., random access memory), non-volatile storage devices (e.g., read-only memory), flash memory, or any combination of these memories. The system memory 506 may include an operating system 507 and one or more program modules 508, one or more of which are suitable for running software applications 520, such as applications 204, IO managers 206, and other utilities 210. The operating system 507 may, for example, be suitable for controlling the operation of the computing device 502. Furthermore, examples of the present invention may be practiced in conjunction with a graphics library, other operating systems, or any other application, and is not limited to any particular application or system. This basic configuration is Figure 5 522. The computing device 502 may have additional features or functionality. For example, the computing device 502 may also include additional (removable and / or non-removable) data storage devices such as, for example, magnetic disks, optical disks, or tapes. Such additional storage devices may be located in the Figure 5 , illustrated by a removable storage device 509 and a non-removable storage device 510.

[0066] As stated above, a number of program modules and data files may be stored in system memory 506. When executed on processing unit 504, program modules 508 (e.g., applications 204, IO manager 206, and other utilities 210) may perform processes including, but not limited to, Figure 3 and Figure 4 Other program modules that can be used according to examples of the present invention may include email and contact applications, word processing applications, spreadsheet applications, database applications, slideshow applications, drawing or computer-aided applications, and the like.

[0067] Furthermore, examples of the present invention may be practiced in circuits including discrete electronic components, in packaged or integrated electronic chips containing logic gates, in circuits utilizing a microprocessor, or on a single chip containing electronic components or a microprocessor. For example, examples of the present invention may be practiced via a system on a chip (SOC), wherein Figure 5Each or many of the components illustrated in the figure can be integrated into a single integrated circuit. This SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which are integrated (or "burned") into a chip substrate as a single integrated circuit. When operated via SOC, the functions described herein can be operated via a dedicated logic integrated on a single integrated circuit (chip) together with other components of the computing device 502. The examples disclosed herein can also be practiced using other technologies capable of performing logical operations (such as, for example, "and", "or", and "not"), including but not limited to mechanical, optical, fluid, and quantum technologies. In addition, examples of the present invention can be practiced in a general-purpose computer or in any other circuit or system.

[0068] The computing device 502 may also have one or more input devices 512, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, etc. Output device(s) 514 (such as a display, a speaker, a printer, etc.) may also be included. The foregoing devices are examples and other devices may be used. The computing device 504 may include one or more communication connections 516 that allow communication with other computing devices 518. Examples of suitable communication connections 516 include, but are not limited to, RF transmitter, receiver, and / or transceiver circuitry; Universal Serial Bus (USB), parallel and / or serial ports.

[0069] The term "computer-readable medium" as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in accordance with any method or technology for storing information (such as computer-readable instructions, data structures, or program modules). System memory 506, removable storage device 509, and non-removable storage device 510 are all examples of computer storage media (i.e., memory storage devices). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other article that can be used to store information and can be accessed by computing device 502. Any such computer storage medium may be part of computing device 502. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0070] Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media may include wired media such as a wired network or direct-wired connection and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0071] Fig. 6A and Figure 6B A mobile computing device 600 is illustrated, with which examples of the present invention may be practiced, such as a mobile phone, a smart phone, a tablet personal computer, a laptop computer, etc. For example, the mobile computing device 600 may be used to implement the client nodes 202 and 208. Fig. 6A , illustrates an example of a mobile computing device 600 for implementing an example. In a basic configuration, the mobile computing device 600 is a handheld computer having both input elements and output elements. The mobile computing device 600 typically includes a display 605 and one or more input buttons 610, which allow a user to input information into the mobile computing device 600. The display 605 of the mobile computing device 600 can also be used as an input device (e.g., a touch screen display). If included, an optional side input element 615 allows further user input. The side input element 615 can be a rotary switch, a button, or any other type of manual input element. In an alternative example, the mobile computing device 600 can include more or fewer input elements. For example, the display 605 may not be a touch screen in some examples. In yet another alternative example, the mobile computing device 600 is a portable telephone system, such as a cellular phone. The mobile computing device 600 can also include an optional keypad 635. The optional keypad 635 can be a physical keypad or a "soft" keypad generated on the touch screen display. In various examples, output elements include a display 605 for showing a graphical user interface (GUI), a visual indicator 620 (e.g., a light emitting diode), and / or an audio transducer 625 (e.g., a speaker). In some examples, the mobile computing device 600 includes a vibration transducer for providing tactile feedback to the user. In yet another example, the mobile computing device 600 includes input and / or output ports for sending or receiving signals to or from an external device, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., an HDMI port).

[0072] Figure 6B6 is a block diagram illustrating the architecture of one example of a mobile computing device. That is, mobile computing device 600 may include system (i.e., architecture) 602 to implement some examples. In one example, system 602 is implemented as a "smart phone" capable of running one or more applications (e.g., browser, email, calendaring, contact manager, messaging client, game, and media client / player). In some examples, system 602 is integrated as a computing device, such as an integrated personal digital assistant (PDA) and a wireless phone.

[0073] One or more application programs 666 may be loaded into the memory 662 and run on or in association with the operating system 664. Examples of application programs include a phone dialer program, an email program, a personal information management (PIM) program, a word processing program, a spreadsheet program, an Internet browser program, a messaging program, and the like. The system 602 also includes a non-volatile storage area 668 within the memory 662. The non-volatile storage area 668 may be used to store persistent information that should not be lost if the system 602 is powered off. The application programs 666 may use and store information in the non-volatile storage area 668, such as emails or other messages used by the email application, and the like. A synchronization application (not shown) also resides on the system 602 and is programmed to interact with a corresponding synchronization application resident on the host to keep the information stored in the non-volatile storage area 668 synchronized with the corresponding information stored at the host. As should be appreciated, other applications may be loaded into the memory 662 and executed on the mobile computing device 600 , including the applications 204 , IO manager 206 , and other utilities 210 described herein.

[0074] The system 602 has a power supply 670, which may be implemented as one or more batteries. The power supply 670 may further include an external power source, such as an AC adapter or a powered docking cradle that replenishes or recharges the batteries.

[0075] The system 602 may include a peripheral device port 678 that performs the function of facilitating a connection between the system 602 and one or more peripheral devices. Transmissions to and from the peripheral device port 672 are performed under the control of the operating system 664. In other words, communications received by the peripheral device port 678 may be propagated to the application 666 via the operating system 664, and vice versa.

[0076] The system 602 may also include a radio 672 that performs the functions of transmitting and receiving radio frequency communications. The radio 672 facilitates wireless connectivity between the system 602 and the "outside world" via a communications carrier or service provider. Transmissions to and from the radio 672 are performed under the control of the operating system 664. In other words, communications received by the radio 672 may be propagated to the application 666 via the operating system 664, and vice versa.

[0077] The visual indicator 620 can be used to provide a visual notification, and / or the audio interface 674 can be used to generate an audible notification via an audio transducer 625. In the illustrated example, the visual indicator 620 is a light emitting diode (LED) and the audio transducer 625 is a speaker. These devices can be directly coupled to the power supply 670 so that when activated, even if the processor 660 and other components may be turned off to save battery power, they remain connected to the duration specified by the notification mechanism. The LED can be programmed to remain on indefinitely until the user takes action to indicate the power-on condition of the device. The audio interface 674 is used to provide an audible signal to the user and receive an audible signal from the user. For example, in addition to being coupled to the audio transducer 625, the audio interface 674 can also be coupled to a microphone to receive an audible input, such as to facilitate a telephone conversation. According to an example of the present invention, as will be described below, the microphone can also serve as an audio sensor to facilitate the control of the notification. The system 602 can further include a video interface 676, which enables the operation of the onboard camera 630 to record still images, video streams, and the like.

[0078] The mobile computing device 600 implementing the system 602 may have additional features or functionality. For example, the mobile computing device 600 may also include additional (removable and / or non-removable) data storage devices, such as magnetic disks, optical disks, or tapes. Such additional storage devices may be stored in a variety of formats, such as memory cards, memory cards, and other storage devices. Figure 6B , illustrated by non-volatile storage area 668.

[0079] Data / information generated or captured by mobile computing device 600 and stored via system 602 may be stored locally on mobile computing device 600 as described above, or the data may be stored on any number of storage media that can be accessed by the device via radio 672 or via a wired connection between mobile computing device 600 and a separate computing device associated with mobile computing device 600, such as a server computer in a distributed computing network such as the Internet. As should be appreciated, such data / information may be accessed via mobile computing device 600, via radio 672, or via a distributed computing network. Similarly, such data / information may be readily transferred between computing devices for storage and use according to well-known data / information transfer and storage means, including email and collaborative data / information sharing systems.

[0080] Figure 7 An example of the architecture of a system for providing an application to one or more client devices is illustrated, and the application reliably accesses the target data on the storage system and handles communication failures as described above. The target data accessed, interacted with, or edited in association with the application 204, the IO manager 206, other utilities 210, and the storage system 214 can be stored in different communication channels or other storage types. For example, various documents can be stored using a directory service 722, a web portal 724, a mailbox service 726, an instant messaging storage repository 728, or a social networking site 730. Applications 204, IO managers 206, other utilities 210, and storage systems 214 can use any of these types of systems, etc., for enabling data utilization as described herein. Server 720 can provide storage system 214 for use by client nodes 202 and 208 operating on a general computing device 502 and (multiple) mobile devices 600 through a network 715. By way of example, network 715 may include the Internet or any other type of local or wide area network, and client nodes 202 and 208 may be implemented as computing device 502 embodied in a personal computer, a tablet computing device, and / or implemented by a mobile computing device 600 (e.g., a smartphone). Any of these embodiments of client computing device 502 or 600 may obtain content from repository 716.

[0081] The present disclosure also provides, among other examples, systems and methods for indicating by an application that a failure during a session should be reported to the application; sending a first access request to a storage system for target data, the first access request being associated with a first identifier; receiving a first access response granting access to the target data; receiving a notification of a first failure; suspending the application based on the notification of the first failure; resuming the application; sending a resume request to the storage system for the target data, the resume request being associated with the first identifier; and receiving a resume response granting access to the target data. In an example, the failure includes at least one of: disconnection from the storage system, unmounting of a file system associated with the storage system, or restarting of the storage system. In a further example, the first identifier is included in the first access request. In a further example, the indication includes providing an indication to an input / output (IO) manager that an IO request that was delayed due to the failure during the session should be reported to the application if it is not completed within a specified time period. In addition, receiving the notification of the first failure may include receiving a notification that a second access request has not been completed. Further, suspending the application may include suspending IO operations and related processing. In addition, the system and method may include completing a cached write request that was not completed before the failure.

[0082] Further descriptions herein disclose systems and methods for receiving a first access request to target data, the target data being stored by a storage system, and the first access request being associated with a request identifier; storing the request identifier in a persistent storage device as a stored first identifier; granting the first access request to the target data; after a failure, receiving a restore request to the target data, the restore request being associated with the request identifier; determining whether the target data has changed since the failure by comparing the request identifier in the restore request with one or more identifiers in the persistent storage device; granting the restore request to the target data when the target data has not changed since the failure; and denying the restore request when the target data has changed since the failure. In an example, the storage system is a shared file system on a server cluster, and determining whether the target data has changed since the failure includes deleting the stored first identifier from the persistent storage device before the restore request is received. Further, in an example, the failure includes at least one of: a connection interruption, a dismounting of a file system associated with the storage system, or a restart of the storage system. In another example, the system and method include locking the target data; and after granting the first access request, releasing the lock on the target data without deleting the first identifier from the persistent storage device. Additionally, in an example, the locking of the target data lasts for a first period of time, and the first period of time may be zero.

[0083] The present disclosure also includes a system, the system including at least one processor configured to execute computer executable instructions; at least one computer readable storage medium storing computer executable instructions, these computer executable instructions when executed by at least one processor provide a storage system, the storage system is configured to: receive a first access request to target data, the target data is stored by the storage system, and the first access request includes a request identifier; store the request identifier in a persistent storage device as a stored first identifier; grant the first access request to the target data; after a failure, receive a recovery request for the target data, the recovery request includes the request identifier and includes a recovery request tag; determine whether the target data has changed since the failure by comparing the request identifier in the recovery request with one or more identifiers in the persistent storage device; when the target data has not changed since the failure, grant the recovery request for the target data; and when the target data has changed since the failure, deny the recovery request. In an example, determining whether the target data has changed since the failure includes deleting the stored first identifier from the persistent storage device before the recovery request is received. In addition, the failure may include at least one of: a connection interruption, a removal of a file system associated with the storage system, or a restart of the storage system. Further, the storage system may be a shared file system on a server cluster.In addition, the locking of the target data may last for a first time period, and the first time period may be zero.

[0084] References have been made throughout this specification to "one example" or "an example," meaning that a particular described feature, structure, or characteristic is included in at least one example. Thus, use of this phrase may refer to more than just one example. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples.

[0085] However, one skilled in the relevant art may recognize that the examples may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well-known structures, resources, or operations are not shown or described in detail, solely for compliance with not obscuring aspects of the examples.

[0086] Although examples and applications are illustrated and described, it will be understood that the examples are not limited to the precise configuration and resources described above. Various modifications, changes and variations apparent to those skilled in the art may be made in the arrangement, operation and details of the methods and systems disclosed herein without departing from the scope of the examples claimed.

Claims

1. A system for secure data access, comprising: at least one processor; as well as A memory storing instructions, wherein the instructions, when executed by the at least one processor, perform a set of operations, the operations comprising: generating, by the application, an indication for enabling fault reporting of a fault during a communication session with the storage system; Sending a first access request for target data to the storage system, the first access request being associated with a first request identifier, the first request identifier being used to identify the application and being associated with the target data; storing, by the system, the first request identifier; receiving a first access response granting access to the target data; receiving notification of a first fault; suspending the application based on the notification of the first fault; restoring the application; sending a restore request for the target data to the storage system, the restore request being associated with the first request identifier; and A restore response is received granting access to the target data.

2. The system according to claim 1, wherein the fault comprises at least one of the following: disconnecting from the storage system; unmounting of a file system associated with the storage system; and A restart of the storage system.

3. The system of claim 1, wherein the indication for enabling fault reporting is provided to an input / output (IO) manager, and wherein access requests that were delayed due to the fault during the communication session are reported to the application.

4. The system of claim 3, wherein the first failure notification is received from the IO manager, and wherein resuming the application occurs when a resume notification is received from the IO manager. 5 . The system of claim 1 , wherein the notification of the first fault includes additional fault information describing at least one of the first fault and an expected duration of the first fault. The system according to claim 1 , wherein suspending the application comprises suspending IO operations and related processing of the application.

7. The system of claim 1, wherein receiving notification of the first failure comprises receiving notification that a second access request has not been completed.

8. The system of claim 1, wherein the resume request includes a flag indicating that the resume request is a request to resume the communication session.

9. The system of claim 1, further comprising completing cached write requests that were not completed prior to the first failure.

10. A computer-implemented method, the method comprising: enabling, by the input / output IO manager, fault reporting of faults during a communication session with the storage system; Sending a first access request for target data to the storage system, the first access request being associated with a first request identifier, the first request identifier being used to identify an application and being associated with the target data; storing the first request identifier; receiving a first access response granting access to the target data; receiving notification of a first failure from the IO manager; suspending the application based on the notification of the first fault; restoring the application; Sending a recovery request for the target data to the storage system, wherein the recovery request is associated with the first request identifier; as well as A restore response is received granting access to the target data.

11. The computer-implemented method of claim 10, wherein the failure comprises at least one of: disconnecting from the storage system; unmounting of a file system associated with the storage system; and A restart of the storage system. 12 . The computer-implemented method of claim 10 , wherein the notification of the first fault includes additional fault information describing at least one of the first fault and an expected duration of the first fault.

13. The computer implemented method of claim 10, wherein resuming the application occurs when a resume notification is received from the IO manager.

14. The computer-implemented method of claim 10, wherein receiving notification of the first failure comprises receiving notification that a second access request has not been completed.

15. The computer-implemented method of claim 10, wherein the resume request includes a flag indicating that the resume request is a request to resume the communication session.

16. A computer-implemented method, the method comprising: generating, by the application, an indication for enabling fault reporting of a fault during a communication session with the storage system; Sending a first access request for target data to the storage system, the first access request being associated with a first request identifier, the first request identifier being used to identify the application and being associated with the target data; storing the first request identifier; receiving a first access response granting access to the target data; receiving notification of a first fault; suspending the application based on the notification of the first fault; receiving a notification of a resolution of the first fault; based on the resolved notification, resuming the application; Sending a recovery request for the target data to the storage system, wherein the recovery request is associated with the first request identifier; as well as A restore response is received granting access to the target data.

17. The computer-implemented method of claim 16, wherein the failure comprises at least one of: disconnecting from the storage system; unmounting of a file system associated with the storage system; and A restart of the storage system.

18. The computer implemented method of claim 16, wherein the indication to enable fault reporting is provided to an input / output (IO) manager, and wherein access requests delayed due to the fault during the communication session are reported to the application.

19. The computer implemented method of claim 16, wherein the first failure notification is received from an IO manager, and wherein the resolved notification is received from the IO manager.

20. The computer-implemented method of claim 16, wherein the notification of the first fault includes additional fault information describing at least one of the first fault and an expected duration of the first fault.

Images