Abstract: An example method for optimizing data deletion in a storage system comprises: monitoring one or more attributes associated with a storage volume associated with a file system; and setting, based on the monitoring of the one or more attributes, a discard option to be either enabled or disabled for the storage volume, wherein when the discard option is enabled, the file system is configured to automatically issue a discard request in response to a request to delete data stored on one or more blocks within a storage device associated with the storage volume, the discard request configured to command the storage device to free the one or more blocks for use by the file system to store additional data; and when the discard option is disabled, the file system does not automatically issue the discard request in response to the request to delete the data.

Abstract: An example method for optimizing data deletion in a storage system comprises: detecting a command to delete data from a storage volume using a file system, the data stored on one or more blocks within a storage device associated with the storage volume; monitoring a load metric associated with the storage volume, the load metric indicative of a dynamically changing operational load of the storage volume; and initiating, based on the detecting the command and on the monitored load metric, a discard request for the storage device, the discard request commanding the storage device to indicate that the one or more blocks are free for use by the file system to store additional data.

Abstract: An illustrative method includes receiving a write request to write payload data to a virtual storage volume; transmitting the write request to a plurality of storage nodes each storing a replica of the virtual storage volume; acknowledging the write request only after a quorum of the storage nodes has stored the payload in their respective kernel memory; and flushing the payloads stored in each kernel memory to persistent storage only after a threshold number of outstanding write requests that have been acknowledged, but not yet flushed, has been reached, the flushing configured to optimize performance for synchronous workloads.

Abstract: In some embodiments, storage operation routing in a container system may include receiving, by a container storage system executing on a node within a container system, a storage operation configured to be performed with respect to a storage resource; determining whether the storage resource is locally accessible at the node; and routing the storage operation based on the determining of whether the storage resource is locally accessible at the node. For example, the routing may be performed such that when the storage resource is not locally accessible at the node, the routing is by way of both a kernel space and a user space of the node, and when the storage resource is locally accessible at the node, the routing is contained within the kernel space of the node. Corresponding methods and systems are also disclosed.

Abstract: An illustrative distributed storage system detects a request to resize an online volume that provides persistent storage for a containerized application running in a container system, wherein the online volume is backed by a virtual block device created in device namespace using a device mapper virtualization of data blocks of one or more storage devices. The distributed storage system performs, in response to the request, a resize process to resize the online volume. The resizing of the online volume includes resizing the virtual block device. In some examples, a file system implemented on the virtual block device is also resized while the online volume is online. The storage system may manage inflight IOs over the virtual block device and the online volume such that the resize process is performed without error.

Abstract: An illustrative method includes receiving a write request to write payload data to a virtual storage volume; transmitting the write request to a plurality of storage nodes each storing a replica of the virtual storage volume; acknowledging the write request only after a quorum of the storage nodes has stored the payload in their respective kernel memory; and flushing the payloads stored in each kernel memory to persistent storage only after a threshold number of outstanding write requests that have been acknowledged, but not yet flushed, has been reached, the flushing configured to optimize performance for synchronous workloads.

Abstract: A synchronous write operation is decomposed into an asynchronous write operation and a separate flush operation. The payload of the write operation is sent a plurality of storage nodes hosting replicas of a virtual storage volume. The write operation is only acknowledged after the payload is stored in kernel memory in a quorum of storage nodes hosting replicas. Write operations are only flushed to persistent storage after a predetermined window of time has transpired or after a threshold number of outstanding write operations that have been acknowledged, but not yet flushed, has been reached.

Abstract: An illustrative storage system provides distributed storage for use by containerized applications running in a container system. In some implementations, this includes converting data blocks of storage resources to distributed persistent storage such as thin-provisioned volumes for use by the containerized applications. In some implementations, the conversion includes using a device mapper to virtualize the data blocks of the storage resources to create a virtual storage pool backing datastore in which the thin-provisioned volumes are created.

Abstract: A technique is introduced to support on-disk software image encryption. Image of a software component deployed to a host is encrypted when the image is created and/or its content is changed, before such image of the software component is being saved to a non-volatile storage of the host. The encrypted image of the software component is decrypted only at startup and/or resume time of the software component. Once decrypted, the image of the software component is loaded into a volatile storage of the host so that the software component can be up and running.

Abstract: A novel approach is introduced for secured live migration of a software component currently running on one hosting device to another hosting device. One or more pages of the software component are encrypted before migration of the software component, and are later decrypted after the migration is complete. The software component is kept operational during the encryption, migration, and decryption of the software component. The one or more pages to be encrypted and decrypted can be selected based on data sensitivity and/or other criteria.