Applications may allocate and deallocate persistent objects within transactions used to access persistent data. An allocator's persistent metadata may be lazily persisted when the enclosing transaction commits. An allocator's metadata may be divided into persistent and nonpersistent portions while the heap may be divided into shared and thread-private superblocks. The persisting of the effects of allocation/deallocation calls may be lazily performed and bundled with the enclosing transaction's commit operation related persist barriers. A transaction may maintain an allocation log of the allocation/deallocation calls made by the transaction. An allocation log may be hosted in persistent memory and updated during allocation/deallocation calls. No persist barriers may be used during allocation/deallocation calls. Before a transaction commits, its updates and allocation log may be persisted. Once the transaction has been committed, the allocation log may be applied to the heap's corresponding metadata.

Systems implementing copy-on-write (COW) as described herein may reduce the number of persist barriers executed within a transaction. For instance, a system may eliminate some, most or all persist barriers related to memory allocation/deallocation in COW transactions. A COW implementation may introduce an extra level of indirection between a persistent type instance and the real data type it encloses. A persistent type may include pointers to old and new versions of the enclosed type's instances. Before modifying an object, a transaction may modify a copy-on-write persistent object and create a new copy of the payload. The modified object may be added to a list of objects written to by the transaction. The transaction may be committed by issuing persist barriers in the commit operation.

Undo logging for persistent memory transactions may permit concurrent transactions to write to the same persistent object. After an undo log record has been written, a single persist barrier may be issued. The tail pointer of the undo log may be updated after the persist barrier, and without another persist barrier, so the tail update may be persisted when the next log record is written and persisted. Undo logging for persistent memory transactions may rely on inferring the tail of an undo log after a failure rather than relying on a guaranteed correct tail pointer based on persisting the tail after every append. Additionally, transaction version numbers and checksum information may be stored to the undo log enabling failure recovery.

A method includes storing a data group in a first zone of a plurality of radial zones of a data storage disc. Each different one of the plurality of zones has a different throughput level. The method further includes obtaining information related to an access frequency of the data group stored in the first zone of the plurality of zones. Based on the information related to the access frequency of the data group and the different throughput levels of the different zones, a determination is made as to whether to migrate the data group from the first zone of the plurality of zones to a second zone of the plurality of zones.

A method includes identifying a plurality of DST client modules affiliated with data for storage in the DST network. A corresponding subset of a plurality of DST execution units are identified for each of the plurality of DST client modules. The data is encoded into a plurality of slices based on at least one dispersal parameter, the number of the plurality of slices corresponding to a number of the plurality of DST execution units included in a superset formed from the union of each subset of a plurality of DST execution units corresponding to each of the plurality of DST client modules. The plurality of slices are sent for storage in the superset formed from the union of each subset of a plurality of DST execution units.

In an embodiment, before modifying a persistent ORL (ORL), a database management system (DBMS) persists redo for a transaction and acknowledges that the transaction is committed. Later, the redo is appended onto the ORL. The DBMS stores first redo for a first transaction into a first PRB and second redo for a second transaction into a second PRB. Later, both redo are appended onto an ORL. The DBMS stores redo of first transactions in volatile SRBs (SLBs) respectively of database sessions. That redo is stored in a volatile shared buffer that is shared by the database sessions. Redo of second transactions is stored in the volatile shared buffer, but not in the SLBs. During re-silvering and recovery, the DBMS retrieves redo from fast persistent storage and then appends the redo onto an ORL in slow persistent storage. After re-silvering, during recovery, the redo from the ORL is applied to a persistent database block.

A storage system includes a first storage control device including a first memory being a volatile memory and a first processor, and a second storage control device including a second memory being a non-volatile memory and a second processor, wherein the second processor is configured to receive a first write request to write first data into a first storage device, store the first data into the second memory, and transmit the first data to the first storage control device, the first processor is configured to store the first data into the first memory, and transmit a first notification to the second storage control device, and the second processor is configured to receive the first notification, transmit a first completion notification in response to the first write request, and execute processing to write the first data, stored in the second memory, into the first storage device.

Example implementations relate to a storage memory direct access (SMDA) provider. The SMDA provider may pin a storage memory region to a memory address of a consumer machine, the storage memory region corresponding to a storage range of a storage device requested by the consumer machine. The SMDA provider may atomically commit data in the storage memory region accessed by the consumer machine via the memory address.

Provided is an image forming apparatus performing effective automated storage tiering. When the system control part of the CPU causes the image processing part to perform image processing of data read from the SSD having a processing speed higher than that of the HDD, the tiering control part measures a ratio of an idle time by the image processing relative to a usage ratio per unit time of the CPU, and determines a movement destination of the data.

An illustrative method includes a storage-aware serverless function management system determining a status of a serverless system that implements one or more serverless functions configured to access one or more components of a storage system, determining a utilization of the storage system, and requesting that the storage system adjust storage of data in the storage system based on the status of the serverless system and the utilization of the storage system.