Office Action 1: Non-Final Rejection (2024-01-18)
Rejection types: 103 - Obviousness

CLAIMS:
CLAIMS

What is claimed is:

1\. A storage system, comprising:
storage nodes; and
compute nodes;
wherein the compute nodes comprise:
source compute nodes that are configured to (a) receive, during source storage periods, write requests for storing content in the storage system, (b) write, during the source storage periods, the content into the storage nodes, and (c) remain deactivated during replication periods; and
replication compute nodes that are configured to (a) read the content from the storage nodes during the replication periods, (b) participate in outputting the content to one or more data recovery sites during the replication periods, and (c) remain deactivated during the source storage periods.

2\. The storage system according to claim 1 wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network; wherein the replication compute nodes are not connected to the external network.

3\. The storage system according to claim 1 wherein the replication compute nodes are con- figured to participate in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system.

4\. The storage system according to claim 1 wherein the source compute nodes are in commu- nication with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network.

5\. The storage system according to claim 1 wherein the storage nodes are configured to un- dergo a reboot process at beginnings of the replication period.

6\. The storage system according to claim 1 comprising a controller that is configured to dy- namically allocate compute nodes of the storage system to act as replication compute nodes or as source compute nodes.

7\. The storage system according to claim 1 comprising a controller that is configured to de- activate the replication compute nodes during the source storage periods, deactivate the source compute nodes during the replication periods, activate replication compute nodes during the replication periods, and activate the source compute nodes during the source storage periods.

8\. The storage system according to claim 1 wherein at least some of the compute nodes com- prise a deactivation unit for selectively activating and deactivating one or more compute nodes.

9\. The storage system according to claim 1 comprising a controller that is configured to con- trol a timing of the source storage periods and to control a timing of the replication peri- ods.

10\. The storage system according to claim 1 wherein at least some of the compute nodes are configured to control a timing of the source storage periods and a timing of the replication periods.

11\. A method for protecting a disaster recovery site, the method comprises:
receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system, writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system;
maintaining replication compute nodes of the storage system deactivated during the source storage periods;
reading the content by the replication compute nodes from the storage nodes during replication periods;
participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods;
maintaining the source compute nodes deactivated during the source storage periods.

12\. The method according to claim 11 wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network; wherein the replication compute nodes are not connected to the external network.

13\. The method according to claim 11 comprising participating, by the replication compute nodes, in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system.

14\. The method according to claim 11 wherein the source compute nodes are in communica- tion with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network.

15\. The method according to claim 11 comprising rebooting the storage nodes at beginnings of the replication period.

16\. The method according to claim 11 comprising dynamically allocating the compute nodes to act as replication compute nodes or as source compute nodes.

17\. The method according to claim 11 comprising deactivating, by a controller, replication compute nodes during the source storage periods; deactivating the source compute nodes during the replication periods, activating the replication compute nodes during the replica- tion periods, and activating the source compute nodes during the source storage periods.

18\. The method according to claim 11 comprising selectively activating and deactivating one or more compute nodes by one or more deactivation units of one or more of the compute nodes.

19\. The method according to claim 11 controlling, by a controller, a timing of the source stor- age periods and a timing of the replication periods.

20\. The method according to claim 11 comprising controlling, by at least some of the compute nodes, a timing of the source storage periods and a timing of the replication periods.

21\. A non-transitory computer readable medium that stores instructions for:
receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system;
writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system; maintaining replication compute nodes of the storage system deactivated during the source storage periods;
reading the content by the replication compute nodes from the storage nodes during replication periods;
participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; and
maintaining the source compute nodes deactivated during the source storage periods. 14 15 16 17

OFFICE ACTION:
DETAILED ACTION
Notice of Pre-AIA  or AIA  Status
1.    	The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
2.    	Claims 1-21 are pending. Claims 1, 11, and 21 are in independent forms.
Priority
3.    	No foreign priority has been claimed.
Information Disclosure Statement
4.    	No information disclosure statements filed with these application.
Drawings
5.    	The drawings filed on 10/26/2021 are accepted by the examiner.
Claim Objections                                                                                                                                                          6.	Claims 2-12 and 12-20 are objected to because of the following informalities: Claims 2-12 and 12-20 requires a comma at the end such as the storage system according to claim 1, .  Appropriate correction is required.
Claim Rejections - 35 USC § 103
7.	The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
8.	Claims 1-21 are rejected under 35 U.S.C. 103 as being unpatentable overZafman et al. US Patent Application Publication No. 2021/0191634 (hereinafter Zafman) in view of Grunwald US Patent Application Publication No. 2021/0081432 (hereinafter Grunwald).
Regarding claim 1,  Zafman discloses a storage system (Fig. 1, storing system 104), comprising:
“storage nodes” (Fig. 1, storage nodes 106 a-d); and “compute nodes” (Fig. 1, storing system 104); wherein the compute nodes comprise:
“source compute nodes that are configured to (a) receive, during source storage periods, write requests for storing content in the storage system (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both), (b) write, during the source storage periods, the content into the storage nodes (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both), and
“replication compute nodes that are configured to (a) read the content from the storage nodes during the replication periods (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses (c) remain deactivated during replication periods; (b) participate in outputting the content to one or more data recovery sites during the replication periods; and (c) remain deactivated during the source storage periods.
However, in analogues art, Grunwald discloses (c) remain deactivated during replication periods (see Grunwald par. 0355, a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod);  (b) participate in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server),  and (c) remain deactivated during the source storage periods (see Grunwald par. 0355, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod);
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 2 and 12,  Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network (see Grunwald Fig. 2B, par. 0075, storage cluster 161 is enclosed within a single chassis 138. External port 176 is coupled to storage nodes 150 through communications interconnect 173); wherein the replication compute nodes are not connected to the external network (see Grunwald par. 0068, a storage cluster that stores user data, such as user data originating from one or more user or client systems or other sources external to the storage cluster. The storage cluster distributes user data across storage nodes housed within a chassis, or across multiple chassis, using erasure coding and redundant copies of metadata).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 3 and 13, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses wherein the replication compute nodes are configured to participate in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system (see Grunwald par. 0033, The storage drives 171A-F may respond by sending a response message to the storage array controller 110A-D that includes the location of control information for the storage drive 171A-F. Responsive to receiving the response message, storage array controllers 110A-D may issue a request to read data stored at the address associated with the location of control information for the storage drives 171A-F).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 4 and 14, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses wherein the source compute nodes are in communication with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network (see Grunwald par. 0333, in response to a recovery event—such as a source data repository 602 losing a connection with a host computer (not depicted) or applications sending storage operations, performance degradation beyond a threshold value, storage capacity exceeding a threshold value, or a degradation in response times—the target data repository 624 may be promoted to handle all further storage operations from the host computer, and another data repository may be selected. In this example, the replica link from the original source data repository 602 to the target data repository 624 may be reconfigured to flip directions, where the target data repository 624 becomes a new source data repository and another data repository becomes a new target data repository, and where other replica link characteristics stay the same).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 5 and 15, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses wherein the storage nodes are configured to undergo a reboot process at beginnings of the replication period (see Grunwald par. 0212, Since each storage system will have its own copy of the list, and since two independent storage systems can't update their local copy at exactly the same time, and since the local copy is all that is available on a reboot or in various fault scenarios, care must be taken to ensure that transient inconsistencies don't cause problems. For example, if one storage systems is in-sync for a pod and a second storage system is added, then if the second storage system is updated to list both storage systems as in-sync first, then if there is a fault and a restart of both storage systems, the second might startup and wait to connect to the first storage system while the first might be unaware that it should or could wait for the second storage system).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 6 and 16, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses comprising a controller that is configured to dynamically allocate compute nodes of the storage system to act as replication compute nodes or as source compute nodes (see Grunwald par. 0335, there may be a dynamic relationship of volumes to pods, where the dynamic collection of volumes within a pod may be related to a clock value within the update stream on a source storage system. For example, a checkpoint may introduce volumes to a pod, change volume characteristics (name, size, etc.) and may remove volumes. In this example, if there are protection groups or some similar organizational concept within a pod, then these protection groups may also change with those changes being propagated through checkpoints. In this way, a near-sync target storage system may actually take over relatively seamlessly as a periodic replication source with all relationships intact, minus whatever time difference the last processed checkpoint is from the previous active source).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 7 and 17, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses comprising a controller that is configured to deactivate the replication compute nodes during the source storage periods, deactivate the source compute nodes during the replication periods, activate replication compute nodes during the replication periods, and activate the source compute nodes during the source storage periods (see Grunwald par. 0355, a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 8 and 18, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Grunwald further discloses wherein at least some of the compute nodes comprise a deactivation unit for selectively activating and deactivating one or more compute nodes (see Grunwald par. 0332, if for some reason, such as a recovery event on the source data repository 602 based on data loss or based on a user or application requesting access to the replica volume or based on a failover request to begin using the replica volume 634 as a primary or user-accessible volume, then the target data repository 624 may promote, or activate, the replica volume 634. In response, the existing checkpoints in the metadata log 626 may be replayed to generate a version of the tracking volume 632 consistent with a most recent checkpoint received, and the tracking volume 632 may be used to create a version of the source volume 658).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 9 and 19, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Zafman further discloses comprising a controller that is configured to control a timing of the source storage periods and to control a timing of the replication periods (see Zafman par. 0024, After generating the target number of replicas 110a-c in the storage system 104, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both. Updating replicas asynchronously may introduce less latency than synchronous replication. However, updating replicas asynchronously may also decrease the durability of the storage system 104, because if the storage system 104 fails in the intervening time period before all of the replicas 110a-c are updated, there are fewer up-to-date replicas from which to pull data).
Regarding claims 10 and 20, Zafman in view of Grunwald discloses the storage system according to claim 1 the method according to claim 11
Zafman further discloses wherein at least some of the compute nodes are configured to control a timing of the source storage periods and a timing of the replication periods (see Zafman pars. 0010-0011, Asynchronous replication involves updating the replicas for a piece of content asynchronously over a time period after receiving a write request, so that all of the replicas are “eventually” consistent with one another. Asynchronous replication can introduce less latency into the storage system than synchronous replication, which involves updating all of the replicas synchronously so that they are all “immediately” consistent with one another. But asynchronous replication can also decrease the durability of the storage system. This is because if the storage system fails in the intervening time period before all of the replicas are updated, there are fewer up-to-date replicas from which to pull data).
Regarding claim 11, Zafman discloses a method for protecting a disaster recovery site, the method comprises:
“receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system” (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system” (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“reading the content by the replication compute nodes from the storage nodes during replication periods” (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses maintaining the source compute nodes deactivated during the source storage periods; participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; maintaining replication compute nodes of the storage system deactivated during the source storage periods.
However, in analogues art, Grunwald discloses maintaining the source compute nodes deactivated during the source storage periods (see Grunwald par. 0355, a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod);  participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server),  maintaining replication compute nodes of the storage system deactivated during the source storage periods (see Grunwald par. 0355, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod);
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claim 21, Zafman discloses a non-transitory computer readable medium that stores instructions for:
“receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system” (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system” (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“reading the content by the replication compute nodes from the storage nodes during replication periods” (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses maintaining replication compute nodes of the storage system deactivated during the source storage periods; participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; and maintaining the source compute nodes deactivated during the source storage periods.
However, in analogues art, Grunwald discloses maintaining replication compute nodes of the storage system deactivated during the source storage periods (see Grunwald par. 0355, a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod);  participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server); and maintaining the source compute nodes deactivated during the source storage periods (see Grunwald par. 0355, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen et al. (US 2020/0026429): discloses A storage system in one embodiment is configured to participate as a source storage system in a synchronous replication process with a target storage system. In verifying synchronously replicated data, the source storage system generates a current snapshot for one or more storage volumes subject to synchronous replication to the target storage system, identifies a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes, obtains content-based signatures for respective ones of the changed pages, assigns the changed pages to a page group, generates a group signature for the page group based at least in part on the content-based signatures of the pages of the page group, and sends the group signature to the target storage system. The group signature is configured to allow the target storage system to determine if the page group contains at least one page that is inconsistent between the source and target storage systems.
Ekins (US 2022/0215111): discloses Data protection for container storage, including: assigning, to a container storage volume of a storage system, a volume-level access policy; and determining whether to allow access to the container storage volume based on the volume-level access policy and one or more attributes of a request for the access, including allowing the access responsive to the one or more attributes meeting the volume-level access policy or denying the access responsive to the one or more attributes failing to meet the volume-level access policy.

APPLICANT REBUTTAL: REMARKS
STATUS OF CLAIMS
Claims 1-21 are pending.
Claims 1-21 were rejected.
Claims 2-10 and 12-20 have been objected to.
Claims 1-21 and have been amended.
The support for the amendment can be found at least in paragraphs [0030], [0036]- [0037].
No new matter has been added.
Claim Objections
In the Office Action, the Examiner objected to claims 2-12 (should be: 2-10) and 12-20 because of alleged informalities. Claims 2-10 and 12-20 have been amended in order to cure these informalities. Accordingly, Applicants request withdrawal of the objection.
35 USC 103 REJECTIONS
Claims 1-21 stand rejected under 35 USC 103 as being unpatentable over Zafman et al. (US Publication 2021/0191634), hereinafter "Zafman", in view of Grunwald (US publication 2021/0081432), hereinafter "Grunwald".
This rejection is traversed.
Zafman teaches that a single storage node performs both the reception of write requests from the users as well as replicating the writes to other storage nodes that stores replicas. See for example paragraph [0024]:
...the storage system 104 may
receive a write request
associated with the content 108 from the client devices 102. In some examples, the storage system
can respond to
such write requests by
u
p
datin
g
the replicas
In contrast to Zafman that teaches that the same storage node is responsible for both receiving a write request from the client as well as replicating to other storage nodes, claim 1 of the present invention recites two types of compute nodes that differ from each other by the steps recited in claim 1 and that they are configured to perform: (i) the source compute nodes are configured to
receive write requests
for storing content in the storage system and to write the content into the storage nodes of the same storage system; (ii) the replication compute nodes perform different steps according to claim 1: outputing the content (that was written to the storage nodes of the storage system by the source compute nodes) to one or more
data recovery sites.
Therefore, while Zafman teaches that both the receiving from the client and the replication can be performed by the same storage node, claim 1 recites that these two steps are performed by different compute nodes of the storage system.
Furthermore, claim 1 recites that these different steps are not only performed by different compute nodes, but also
at different time periods:
the receving of write requests from the user is done during "source storage periods", while the outputing to one or more data recovery sites is done during "replication periods".
Zafman does not mention time separation between the receprion of write requests and the replication to other storage nodes.
In addition to performing the receprion of write requests and the replication at different time periods, claim 1 further recites that the source compute nodes are
configured
to
remain
non-operational during replication periods (when the replication compute nodes participate in the outputting to data recovery sites), and the replication compute nodes are
configured
to
remain
non-operational during the source storage periods (when the source compute nodes receive of write requests).
The Examiner asserts that the passive pod of Grunwald reads on "remain
non- operational
deactivated
during the source storage periods". The term "passive" described in paragraph [0355] referred to be the examiner, is defined as the target of the replication. A target of a replication is actually operational as it needs to be in communication with the source pod, to receive data from the source pod and to store it in its repository.
Furthermore, paragraph [0355] describes that the passive pod can be target to read requests from host groups. Accepting read requests is
an activity,
and therefore the passive pod cannot be considered as non-operational.
The problem solved by using separate compute nodes for receiving write requests and for participating in outputting to data recovery sites, and configured to be non-operational at different periods - is described in the present application, paragraphs [0029]-[0030].
Neither Zafman nor Grunwald, alone or in combination, teach or suggest all the features of claim 1.
The arguments for claim 1 are applicable to independent claims 11 and 21.
Conclusion

NEXT OFFICE ACTION: DETAILED ACTION
Notice of Pre-AIA  or AIA  Status
1.	This action is responsive to communication filed on 18 April 2024, with acknowledgement of an original application filed on 26 October 2021.
Status of Claims
2.	Claims 1-21 are pending. Claims 1, 11, and 21 are in independent forms. Claims 1-21 has been amended.                                                                               Drawings
3.	The drawings filed on September 09/01/2021 are accepted by the examiner.
Remarks
4. 	The claim objection withdrawn based on the amendment to the objected claims.
Response to Arguments                                                                                                                                                                            5.    	Applicant's arguments filed 18 April 2024 have been fully considered but they are not persuasive.
I) 	In response to applicant's arguments on pages 7-8, Applicant argued that while Zafman teaches that both the receiving from the client and the replication can be performed by the same storage node, claim 1 recites that these two steps are performed by different compute nodes of the storage system. Furthermore, claim 1 recites that these different steps are not only performed by different compute nodes, but also at different time periods:  the receiving of write requests from the user is done during source storage periods, while the outputting to one or more data recovery sites is done during replication periods.  Zafman does not mention time separation between the reception of write requests and the replication to other storage nodes.
.
The examiner respectfully disagrees with the argument. The applicant argued that the Zafman reference fails to disclose receive, during source storage periods, write requests for storing content in the storage system. Contrary to the applicant assertion, as stated in the office action the Zafman reference discloses the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both. Furthermore, Zafman discloses the storage system 104 can receive read and write requests from the client device 102 and distribute them among the storage nodes 106a-d, which can service those requests. The storage system 104 may determine how to distribute the read and write requests among the storage nodes 106a-d based on the load on the storage system 104 or other factors, such as if one or more of the storage nodes 106a-d has failed. the storage system can repeated at predefined intervals during a timespan to dynamically adjust how many replicas of content are stored in the storage system over the timespan, based on the amount of load on the storage system at different points in time during the timespan. updating the replicas for a piece of content asynchronously over a time period after receiving a write request, so that all of the replicas are “eventually” consistent with one another. Asynchronous replication can introduce less latency into the storage system than synchronous replication, which involves updating all of the replicas synchronously so that they are all “immediately” consistent with one another. But asynchronous replication can also decrease the durability of the storage system. This is because if the storage system fails in the intervening time period before all of the replicas are updated, there are fewer up-to-date replicas from which to pull data  (see Zafman pars. 0002, 0011-0017).                                                                                                                             II. 	The amended non-operational addressed in the body of  the rejection below.
Claim Rejections - 35 USC § 103
6.	The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
7.	Claims 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over Zafman et al. US Patent Application Publication No. 2021/0191634 (hereinafter Zafman) in view of Grunwald US Patent Application Publication No. 2021/0081432 (hereinafter Grunwald).
Regarding claim 1,  Zafman discloses a storage system (Fig. 1, storing system 104), comprising:
“storage nodes” (Fig. 1, storage nodes 106 a-d); and “compute nodes” (Fig. 1, storing system 104); wherein the compute nodes comprise:
“source compute nodes that are configured to (a) receive, during source storage periods, write requests for storing content in the storage system (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both), (b) write, during the source storage periods, the content into the storage nodes (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both), and
“replication compute nodes that are configured to (a) read the content from the storage nodes during the replication periods (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses (c) remain non-operational during replication periods; (b) participate in outputting the content to one or more data recovery sites during the replication periods; and (c) remain non-operational during the source storage periods.
However, in analogues art, Grunwald discloses (c) remain non-operational during replication periods (see Grunwald par. 0355, 0034, 0068 a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);  (b) participate in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server),  and (c) remain non-operational during the source storage periods (see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 2 and 12,  Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network (see Grunwald Fig. 2B, par. 0075, storage cluster 161 is enclosed within a single chassis 138. External port 176 is coupled to storage nodes 150 through communications interconnect 173); wherein the replication compute nodes are not connected to the external network (see Grunwald par. 0068, a storage cluster that stores user data, such as user data originating from one or more user or client systems or other sources external to the storage cluster. The storage cluster distributes user data across storage nodes housed within a chassis, or across multiple chassis, using erasure coding and redundant copies of metadata).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 3 and 13, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the replication compute nodes are configured to participate in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system (see Grunwald par. 0033, The storage drives 171A-F may respond by sending a response message to the storage array controller 110A-D that includes the location of control information for the storage drive 171A-F. Responsive to receiving the response message, storage array controllers 110A-D may issue a request to read data stored at the address associated with the location of control information for the storage drives 171A-F).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 4 and 14, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the source compute nodes are in communication with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network (see Grunwald par. 0333, in response to a recovery event—such as a source data repository 602 losing a connection with a host computer (not depicted) or applications sending storage operations, performance degradation beyond a threshold value, storage capacity exceeding a threshold value, or a degradation in response times—the target data repository 624 may be promoted to handle all further storage operations from the host computer, and another data repository may be selected. In this example, the replica link from the original source data repository 602 to the target data repository 624 may be reconfigured to flip directions, where the target data repository 624 becomes a new source data repository and another data repository becomes a new target data repository, and where other replica link characteristics stay the same).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 5 and 15, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the storage nodes are configured to undergo a reboot process at beginnings of the replication period (see Grunwald par. 0212, Since each storage system will have its own copy of the list, and since two independent storage systems can't update their local copy at exactly the same time, and since the local copy is all that is available on a reboot or in various fault scenarios, care must be taken to ensure that transient inconsistencies don't cause problems. For example, if one storage systems is in-sync for a pod and a second storage system is added, then if the second storage system is updated to list both storage systems as in-sync first, then if there is a fault and a restart of both storage systems, the second might startup and wait to connect to the first storage system while the first might be unaware that it should or could wait for the second storage system).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 6 and 16, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses comprising a controller that is configured to dynamically allocate compute nodes of the storage system to act as replication compute nodes or as source compute nodes (see Grunwald par. 0335, there may be a dynamic relationship of volumes to pods, where the dynamic collection of volumes within a pod may be related to a clock value within the update stream on a source storage system. For example, a checkpoint may introduce volumes to a pod, change volume characteristics (name, size, etc.) and may remove volumes. In this example, if there are protection groups or some similar organizational concept within a pod, then these protection groups may also change with those changes being propagated through checkpoints. In this way, a near-sync target storage system may actually take over relatively seamlessly as a periodic replication source with all relationships intact, minus whatever time difference the last processed checkpoint is from the previous active source).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 7 and 17, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses comprising a controller that is configured to deactivate the replication compute nodes during the source storage periods, deactivate the source compute nodes during the replication periods, activate replication compute nodes during the replication periods, and activate the source compute nodes during the source storage periods (see Grunwald par. 0355, a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 8 and 18, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein at least some of the compute nodes comprise a deactivation unit for selectively activating and deactivating one or more compute nodes (see Grunwald par. 0332, if for some reason, such as a recovery event on the source data repository 602 based on data loss or based on a user or application requesting access to the replica volume or based on a failover request to begin using the replica volume 634 as a primary or user-accessible volume, then the target data repository 624 may promote, or activate, the replica volume 634. In response, the existing checkpoints in the metadata log 626 may be replayed to generate a version of the tracking volume 632 consistent with a most recent checkpoint received, and the tracking volume 632 may be used to create a version of the source volume 658).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 9 and 19, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Zafman further discloses comprising a controller that is configured to control a timing of the source storage periods and to control a timing of the replication periods (see Zafman par. 0024, After generating the target number of replicas 110a-c in the storage system 104, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both. Updating replicas asynchronously may introduce less latency than synchronous replication. However, updating replicas asynchronously may also decrease the durability of the storage system 104, because if the storage system 104 fails in the intervening time period before all of the replicas 110a-c are updated, there are fewer up-to-date replicas from which to pull data).
Regarding claims 10 and 20, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Zafman further discloses wherein at least some of the compute nodes are configured to control a timing of the source storage periods and a timing of the replication periods (see Zafman pars. 0010-0011, Asynchronous replication involves updating the replicas for a piece of content asynchronously over a time period after receiving a write request, so that all of the replicas are “eventually” consistent with one another. Asynchronous replication can introduce less latency into the storage system than synchronous replication, which involves updating all of the replicas synchronously so that they are all “immediately” consistent with one another. But asynchronous replication can also decrease the durability of the storage system. This is because if the storage system fails in the intervening time period before all of the replicas are updated, there are fewer up-to-date replicas from which to pull data).
Regarding claim 11, Zafman discloses a method for protecting a disaster recovery site, the method comprises:
“receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system” (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system” (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“reading the content by the replication compute nodes from the storage nodes during replication periods” (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses maintaining the source compute nodes in a non-operational mode during the source storage periods; participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods.
However, in analogues art, Grunwald discloses maintaining the source compute nodes in a non-operational mode during the source storage periods see Grunwald par. 0355, 0034, 0068 a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);  participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server),  maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods ((see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claim 21, Zafman discloses a non-transitory computer readable medium that stores instructions for:
“receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system” (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system” (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“reading the content by the replication compute nodes from the storage nodes during replication periods” (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods; participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; and maintaining the source compute nodes in a non-operational mode during the source storage periods.
However, in analogues art, Grunwald discloses maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods (see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);  participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server); and maintaining the source compute nodes in a non-operational mode during the source storage periods ((see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Conclusion
THIS ACTION IS MADE FINAL.  Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action.  In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action.  In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.

CITED REFERENCE SUMMARIES: Ref US20210191634A1: [content unavailable]
Ref US20210081432A1: Claims:
A method for using lightweight checkpoints in a data storage system, the method comprising: receiving, at a source data repository, one or more updates to one or more datasets stored within the source data repository; generating, based on the one or more updates to the one or more datasets, metadata describing the one or more updates to one or more datasets stored within the source data repository; and generating, based on the metadata describing the one or more updates to the one or more datasets, a lightweight checkpoint of metadata describing an ordered application of the one or more updates to the one or more datasets.
receiving, at a source data repository, one or more updates to one or more datasets stored within the source data repository;
generating, based on the one or more updates to the one or more datasets, metadata describing the one or more updates to one or more datasets stored within the source data repository; and
generating, based on the metadata describing the one or more updates to the one or more datasets, a lightweight checkpoint of metadata describing an ordered application of the one or more updates to the one or more datasets.
The method of claim 1 , further comprising: sending, from the source data repository to a target data repository and independent from sending the lightweight checkpoint to the target data repository, data corresponding to the lightweight checkpoint.
sending, from the source data repository to a target data repository and independent from sending the lightweight checkpoint to the target data repository, data corresponding to the lightweight checkpoint.
The method of claim 1 , wherein an ordered log of metadata includes one or more lightweight checkpoints.
The method of claim 3 , wherein a quantity of updates described by a given lightweight checkpoint is a configurable data replication setting.
The method of claim 3 , wherein the configurable data replication setting is target recovery point objective.
The method of claim 1 , wherein the recovery event is responsive to one or more of: a detected failure, a detected impending failure, or a detected degradation of responsiveness beyond a compliance policy threshold of the source data repository.
The method of claim 1 , wherein the recovery event is not based on a failure and is based on a promotion event to prepare, for testing on the target data repository, a replica of the stored data at the source data repository.
A storage system that includes a computer memory and a computer processor, the computer memory including program instructions that, when executed by the computer processor, cause the storage system to carry out the steps of: receiving, at a target data repository from a source data repository, metadata describing one or more updates to one or more datasets stored within the source data repository; generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and generating, based on the ordered log of metadata, the one or more datasets in accordance with the one or more updates.
receiving, at a target data repository from a source data repository, metadata describing one or more updates to one or more datasets stored within the source data repository;
generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and
generating, based on the ordered log of metadata, the one or more datasets in accordance with the one or more updates.
The storage system of claim 8 , wherein the program instructions, when executed by the computer processor, further cause the storage system to carry out the steps of: receiving, at the target data repository from the source data repository and independent from receiving the metadata describing the one or more updates to the one or more datasets, data corresponding to the one or more updates to the one or more datasets.
receiving, at the target data repository from the source data repository and independent from receiving the metadata describing the one or more updates to the one or more datasets, data corresponding to the one or more updates to the one or more datasets.
The storage system of claim 8 , wherein the ordered log of metadata includes one or more lightweight checkpoints.
The storage system of claim 10 , wherein a quantity of updates described by a given lightweight checkpoint on a configurable data replication setting.
The storage system of claim 10 , wherein the configurable data replication setting is target recovery point objective.
The storage system of claim 8 , wherein the recovery event is responsive to one or more of: a detected failure, a detected impending failure, or a detected degradation of responsiveness beyond a compliance policy threshold of the source data repository.
The storage system of claim 8 , wherein the recovery event is not based on a failure and is based on a promotion event to prepare, for testing on the target data repository, a replica of the stored data at the source data repository.
A method for continuous data protection, the method comprising: generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and generating, on the source data repository and based on the ordered log of metadata, at least a portion of the one or more datasets in accordance with the one or more updates corresponding to a specified point in time.
generating, on the source data repository and based on the ordered log of metadata, at least a portion of the one or more datasets in accordance with the one or more updates corresponding to a specified point in time.
The method of claim 16 , wherein stored data to generate the one or more datasets is available based on garbage collection on the source data repository using both a reference table maintained by a storage controller and also a list of references within the ordered log of metadata.
The method of claim 16 , wherein the ordered log of metadata includes one or more lightweight checkpoints.
The method of claim 16 , wherein a quantity of updates described by a given lightweight checkpoint on a configurable data replication setting.
The method of claim 19 , wherein a quantity of lightweight checkpoints stored on the source data repository is based on a configuration setting that specifies a recovery window of time.
Ref US20200026429: Claims:
1. An apparatus comprising:
a storage system comprising a plurality of storage devices and a storage controller; the storage system being configured to participate as a source storage system in a synchronous replication process with a target storage system; wherein in conjunction with the synchronous replication process, the source storage system in performing data verification operations is further configured: to generate a current snapshot for one or more storage volumes subject to synchronous replication to the target storage system; to identify a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes; to obtain content-based signatures for respective ones of the changed pages; to assign the changed pages to a page group; to generate a group signature for the page group based at least in part on the content-based signatures of the pages of the page group; and to send the group signature to the target storage system; wherein the group signature is configured to allow the target storage system to determine if the page group contains at least one page that is inconsistent between the source and target storage systems; and wherein the source storage system is implemented using at least one processing device comprising a processor coupled to a memory.
2. The apparatus of claim 1 wherein the source storage system is configured to repeat at least a portion of its data verification operations utilizing a different pair of snapshots in each of a plurality of iterations with the current snapshot for one of the iterations becoming the previous snapshot for a subsequent one of the iterations.
3. The apparatus of claim 2 wherein the iterations continue until all replicated data of the one or more storage volumes has been subject to data verification.
4. The apparatus of claim 1 wherein identifying a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes comprises excluding any pages that are in the process of being changed at the time of performance of the data verification operations.
5. The apparatus of claim 4 wherein one or more of the excluded pages in a current iteration of the data verification operations are assigned to a different page group in a subsequent iteration of the data verification operations.
6. The apparatus of claim 1 wherein identifying a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes comprises:
aggregating dirty page data structures of the current and previous snapshots to identify a first set of one or more pages that have changed since a previous iteration of the data verification operations;
excluding from the first set of pages one or more pages identified in one or more dirty page data structures of the one or more storage volumes subject to synchronous replication to obtain a second set of pages; and
identifying the second set of pages as the changed pages.
7. The apparatus of claim 1 wherein the page group has a size that is determined based at least in part on a message buffer size of the source storage system.
8. The apparatus of claim 1 wherein the source storage system is configured to wait for a designated waiting period after generation of the current snapshot in order to ensure that all data of the one or more storage volumes captured by current snapshot has been replicated to the target storage system.
9. The apparatus of claim 1 wherein generating a group signature for the page group based at least in part on the content-based signatures of the pages of the page group comprises generating the group signature as a function of at least one volume pairing label, at least one page offset and the content-based signatures.
10. The apparatus of claim 1 wherein sending the group signature to the target storage system comprises:
generating a volume offset extent list for contiguous page offsets with the volume offset extent list comprising one or more volume offset extents each comprising a volume pairing label, a volume start offset and a length; and
sending the group signature and the volume offset extent list to the target storage system;
wherein the group signature and volume offset extent list are utilized by the target storage system to reconstruct the page group, to generate a group signature for the reconstructed page group, and to determine if there is any inconsistency between the group signature received from the source storage system and the group signature generated in the target storage system for the reconstructed page group.
11. The apparatus of claim 1 wherein the source storage system is configured to initiate a subsequent iteration of the data verification operations responsive to receipt of an indication from the target storage system that there is no inconsistency between the group signature received from the source storage system and a corresponding group signature generated in the target storage system.
12. The apparatus of claim 1 wherein the source storage system is configured to initiate a further phase of the data verification operations to identify one or more particular inconsistent pages of the page group in a current iteration of the data verification operations, responsive to receipt of an indication from the target storage system that there is an inconsistency between the group signature received from the source storage system and a corresponding group signature generated in the target storage system.
13. The apparatus of claim 12 wherein the source storage system in the further phase of the data verification operations is configured send to the target storage system, for each of the pages in the page group, a volume pairing label, a page offset and a content-based signature for that page, so as to allow the target storage system to identify in one or more particular pages of the page group that are inconsistent between the source and target storage systems.
14. The apparatus of claim 1 wherein the source storage system comprises a plurality of storage nodes each comprising one or more of the storage devices and wherein each of the storage nodes of the target storage system further comprises a set of processing modules configured to communicate over one or more networks with corresponding sets of processing modules on other ones of the storage nodes, the sets of processing modules of the storage nodes of the source storage system collectively comprising at least a portion of the storage controller of the source storage system, each of the sets of processing modules comprising one or more control modules, one or more routing modules and one or more data modules, and wherein at least one of the sets of processing modules comprises a management module.
15. A method comprising:
configuring a storage system to participate as a source storage system in a synchronous replication process with a target storage system; and in conjunction with the synchronous replication process, the source storage system performing data verification operations comprising: generating a current snapshot for one or more storage volumes subject to synchronous replication to the target storage system; identifying a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes; obtaining content-based signatures for respective ones of the changed pages; assigning the changed pages to a page group; generating a group signature for the page group based at least in part on the content-based signatures of the pages of the page group; and sending the group signature to the target storage system; wherein the group signature is configured to allow the target storage system to determine if the page group contains at least one page that is inconsistent between the source and target storage systems; and wherein the method is implemented by at least one processing device comprising a processor coupled to a memory.
16. The method of claim 15 wherein identifying a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes comprises excluding any pages that are in the process of being changed at the time of performance of the data verification operations, and wherein one or more of the excluded pages in a current iteration of the data verification operations are assigned to a different page group in a subsequent iteration of the data verification operations.
17. The method of claim 15 further comprising the source storage system initiating a further phase of the data verification operations to identify one or more particular inconsistent pages of the page group in a current iteration of the data verification operations, responsive to receipt of an indication from the target storage system that there is an inconsistency between the group signature received from the source storage system and a corresponding group signature generated in the target storage system.
18. A computer program product comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code when executed by at least one processing device causes said at least one processing device:
to configure a storage system to participate as a source storage system in a synchronous replication process with a target storage system; and in conjunction with the synchronous replication process, to configure the source storage system in performing data verification operations: to generate a current snapshot for one or more storage volumes subject to synchronous replication to the target storage system; to identify a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes; to obtain content-based signatures for respective ones of the changed pages; to assign the changed pages to a page group; to generate a group signature for the page group based at least in part on the content-based signatures of the pages of the page group; and to send the group signature to the target storage system; wherein the group signature is configured to allow the target storage system to determine if the page group contains at least one page that is inconsistent between the source and target storage systems
19. The computer program product of claim 18 wherein identifying a plurality of pages of the current snapshot that have changed since generation of a previous snapshot for the one or more storage volumes comprises excluding any pages that are in the process of being changed at the time of performance of the data verification operations, and wherein one or more of the excluded pages in a current iteration of the data verification operations are assigned to a different page group in a subsequent iteration of the data verification operations.
20. The computer program product of claim 18 wherein the source storage system is configured to initiate a further phase of the data verification operations to identify one or more particular inconsistent pages of the page group in a current iteration of the data verification operations, responsive to receipt of an indication from the target storage system that there is an inconsistency between the group signature received from the source storage system and a corresponding group signature generated in the target storage system.
Ref US20220215111: Claims:
1. A method comprising:
assigning, to a container storage volume, a volume-level access policy, wherein the container storage volume is presented to one or more containers by a storage management service; receiving a request to access the container storage volume; determining whether to allow access to the container storage volume based on the volume-level access policy and one or more attributes of the request; responsive to determining allow access to the container storage volume, issuing from the storage management service to a storage resource, the request; and responsive to determining not allow access to the container storage volume, preventing the request from being serviced by the storage resource.
2. The method of claim 1, wherein determining whether to allow access to the container storage volume comprises allowing the access responsive to the one or more attributes meeting the volume-level access policy.
3. The method of claim 1, wherein determining whether to allow access to the container storage volume comprises denying the access responsive to the one or more attributes failing to meet the volume-level access policy.
4. The method of claim 1, wherein the volume-level access policy indicates one or more geographic access permissions and the one or more attributes comprise a source of the request.
5. The method of claim 1, wherein the volume-level access policy indicates a data sensitivity level and the one or more attributes comprise a security level.
6. The method of claim 1, wherein the volume-level access policy indicates one or more allowable storag
[Truncated to input limit]