Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A persistent data structure store may include an architecture that utilizes dual representations of data hosted in persistent storage coupled with a faster non-persistent cache residing in volatile memory. The persistent data structure store may maintain, in a non-volatile persistent memory, a byte-addressable persistent copy of a data structure storing multiple data values. The persistent data structure store may also maintain a copy of at least some of the data values in a cache copy of the data structure in a volatile memory. When updating values in the data structure, the targeted data value may be updated in the cache copy of the data structure and a log entry specifying the data update may be added to a cross-referencing data operations log from which the data operation will be subsequently applied to the persistent copy of the data structure.

Abstract: 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.

Abstract: 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.

Abstract: A persistent data structure store may include an architecture that utilizes dual representations of data hosted in persistent storage coupled with a faster non-persistent cache residing in volatile memory. The persistent data structure store may maintain, in a non-volatile persistent memory, a byte-addressable persistent copy of a data structure storing multiple data values. The persistent data structure store may also maintain a copy of at least some of the data values in a cache copy of the data structure in a volatile memory. When updating values in the data structure, the targeted data value may be updated in the cache copy of the data structure and a log entry specifying the data update may be added to a cross-referencing data operations log from which the data operation will be subsequently applied to the persistent copy of the data structure.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A storage system to recover and rewrite overwritten data is described. A Shingled Magnetic Recording (SMR) array subsystem within the storage system writes data to multiple adjacent tracks on a number of storage devices, such as hard drives that support shingled magnetic recording. While writing data, the SMR array subsystem detects that one of the storage devices erroneously overwrote a portion of the data on one or more of the tracks. The SMR array subsystem can recover the overwritten portion of data using other portions of the data written to corresponding tracks on the other storage devices that are part of the array. The recovered data can then be rewritten to the array.

Abstract: A storage system to recover and rewrite overwritten data is described. A Shingled Magnetic Recording (SMR) array subsystem within the storage system writes data to multiple adjacent tracks on a number of storage devices, such as hard drives that support shingled magnetic recording. While writing data, the SMR array subsystem detects that one of the storage devices erroneously overwrote a portion of the data on one or more of the tracks. The SMR array subsystem can recover the overwritten portion of data using other portions of the data written to corresponding tracks on the other storage devices that are part of the array. The recovered data can then be rewritten to the array.