Abstract: An example method for dynamic determination of locks for prioritized deployment in a distributed storage system comprises providing, by a storage management system, N locks to a cluster of a distributed storage system, the cluster including a plurality of nodes and the N locks allowing N nodes of the plurality of nodes to each initiate a startup phase during a first time window, wherein N is a number greater than zero; tracking, by the storage management system, application programming interface (API) calls made by the N nodes to a platform of the cluster during the first time window; and providing, by the storage management system based on the tracking, M locks to the cluster, the M locks allowing M nodes of the plurality of nodes to each initiate a startup phase during a second time window subsequent to the first time window, wherein M is a number greater than zero.

Abstract: An example method for prioritizing deployment of nodes in a cluster comprises: determining, at a first time and by a first node of a plurality of nodes in a cluster of a distributed storage system, that a second node having a higher priority than the first node is in a startup phase of the second node; determining, at a second time subsequent to the first time and by the first node, that the second node has completed the startup phase of the second node; and initiating, based on the determining that the second node has completed the startup phase and by the first node, a startup phase of the first node.

Abstract: A storage cluster may include storage nodes. Each storage node may include a storage device. The storage nodes may communicate via a network to provide volumes that are mountable by clients outside the storage cluster. The volumes may be stored on the storage devices. There may be an instruction to generate a cluster-wide snapshot corresponding to a point in time. Based on the instruction, all of the volumes provided by the storage cluster may be identified. A snapshot of each of the identified volumes may be generated. Each volume snapshot may include a copy of the content of the volume as it existed at the point in time. A cluster-wide snapshot may be generated, and the cluster-wide snapshot may include the snapshots of the volumes, among other information.

Abstract: Clients that fail to access a resource may compute backoff times for waiting before retrying to access the resource. The clients may reference a sequence of time windows where the time windows may have increasing numbers of time slots. The clients may select respective time slots in a first time window. If the clients again fail to access the resource, then the time slots selected by the clients may at least partly determine which time slots the clients select in a next (second) time window. The time slot selections in the second time window may be at least partly randomly selected. A client may randomly select a time slot in the second time window from among a proper subset of time slots in the second time window. The proper subset may be based on which time slot the client selected in the first time window.

Abstract: Systems and techniques are described for tracking software code paths. A described technique includes receiving a first log of stack traces that includes a respective stack trace for each of a plurality of calls to access any of a plurality of data objects created during a first execution of an application, generating, for each of the stack traces in the first log, a script for a respective probe that identifies the data object accessed by the call corresponding to the stack trace, a respective instruction called to access the data object, and whether the access is a read or a write access for the data object, generating, for at least one of the probes, a second log that identifies the data object for the respective probe and the data stored in the data object, and generating a representation of the execution of the application using the second log.

Abstract: Systems and techniques are described for tracking software code paths. A described technique includes receiving a first log of stack traces that includes a respective stack trace for each of a plurality of calls to access any of a plurality of data objects created during a first execution of an application, generating, for each of the stack traces in the first log, a script for a respective probe that identifies the data object accessed by the call corresponding to the stack trace, a respective instruction called to access the data object, and whether the access is a read or a write access for the data object, generating, for at least one of the probes, a second log that identifies the data object for the respective probe and the data stored in the data object, and generating a representation of the execution of the application using the second log.