Patent Description:
In instance storage for bare metal storage devices or arrays of storage devices, compression can be used to improve system performance, quality-of-service (QoS), cost-efficiency, etc. For example, instance storage can be used in scenarios having multiple virtual machines accessing a same drive array (e.g., solid state drive (SSD) array) for storage. The instance storage can include multiple SSDs that can be combined for a single system storage that supports multiple virtual machines that can execute one or more servers, and can access the drive array via an interface card and associated firmware.

While compression can change user data size of an application, a mapping table can be used to maintain the mapping between original logical block addressing (LBA) (e.g., LBAs in instance storage) and a new physical location (e.g., LBAs in SSDs). Applications may access SSD array in smaller logical blocks (LBs), such as <NUM> kilobytes (KBs), and interface card firmware for the SSD array can maintain a 4KB based logical-to-physical (L2P) mapping table. As SSD drive array capacity becomes larger, the L2P mapping table maintained by the interface card firmware can also increase in size. For example, a <NUM> terabyte (TB) SSD array may use at least <NUM> gigabyte (GB) dynamic random access memory (DRAM) to cache the L2P table. Having a large DRAM table can result in large cost of DRAM, more DRAM chips using a larger circuit layout, larger power consumption, which can result in SSD temperature, performance (power throttling).

A patent document (Publication No. <CIT> ) relates to handling asynchronous power loss in a memory sub-system that programs sequentially. A system includes a non-volatile memory (NVM), and a volatile memory to store: a zone map data structure (ZMDS) that maps a zone of a logical block address (LBA) space to a zone index; and a high frequency update table (HFUT). A processing device is to: write, within an entry of the HFUT, a value of a zone write pointer corresponding to the zone index for an active zone, wherein the zone write pointer includes a location in the LBA space for the active zone; write, within an entry of the ZMDS, a table index value that points to the entry of the HFUT; and journal metadata of the entry of one the ZMDS or the HFUT affected by a flush transition between the ZMDS and the HFUT.

A patent document (Patent No. <CIT>) generally relates to data storage devices, such as solid state drives. The data storage device includes a controller that includes a compression engine. The controller receives a ZNS append command to write data to a media, such as a non-volatile memory. The compression engine compresses data from a first number of logical blocks to second number of logical blocks. The compressed data is programmed to the media. The compressed data has a media logical block address and a host logical block address, where the media logical block address is the actual LBA where the ZNS append places the data on the media and the host logical block address is the location of the data stored on the media from the host's point of view. The host generates an index of the location of the stored data and the controller programs the index to the relevant location in the media.

A literature document ("<NPL>. ) relates to a configurable mapping layer, called minipage, whose size is set to match I/O request sizes. The minipage-level mapping provides better flexibility in handling small writes at the cost of sequential read performance degradation and a larger mapping table.

A patent document (Publication No. <CIT>) relates to methods, non-transitory machine readable media, and computing devices that manage storage operations directed to dual-port solid state disks (SSDs) coupled to multiple hosts are disclosed. With this technology, context metadata comprising a checksum is retrieved based on a first physical address mapped, in a cached zoned namespace (ZNS) mapping table, to a logical address. The logical address is extracted from a request to read a portion of a file. A determination is made when the checksum is valid based on a comparison to identification information extracted from the request and associated with the file portion. At least the first physical address is replaced in the cached ZNS mapping table with a second physical address retrieved from an on-disk ZNS mapping table, when the determination indicates the checksum is invalid. The file portion retrieved from a dual-port SSD using the second physical address is returned to service the request.

A patent document (Patent No. <CIT>) relates to methods, non-transitory machine readable media, and computing devices that manage resources between multiple hosts coupled to dual-port solid-state disks (SSDs) are disclosed. With this technology, in-core conventional namespace (CNS) and zoned namespace (ZNS) mapping tables are synchronized by a host flash translation layer with on-disk CNS and ZNS mapping tables, respectively. An entry in one of the in-core CNS or ZNS mapping tables is identified based on whether a received storage operation is directed to a CNS or a ZNS of the dual-port SSD. The entry is further identified based on a logical address extracted from the storage operation. The storage operation is serviced using a translation in the identified entry for the logical address, when the storage operation is directed to the CNS, or a zone identifier in the identified entry for a zone of the ZNS, when the storage operation is directed to the ZNS.

A patent document (Publication No. <CIT>) relates to SSD with heterogeneous NVM types. The device includes both low-latency persistent memory and higher-latency nonvolatile memory. The persistent memory may be used for write caching or for journaling. A B-tree may be used to maintain an index of write requests temporarily stored in the persistent memory. Garbage collection may be performed in the nonvolatile memory while write requests are being stored in the persistent memory.

The following presents a simplified summary of one or more implementations in order to provide a basic understanding of such implementations. This summary is not an extensive overview of all contemplated implementations, and is intended to neither identify key or critical elements of all implementations nor delineate the scope of any or all implementations. Its sole purpose is to present some concepts of one or more implementations in a simplified form as a prelude to the more detailed description that is presented later.

In an example, a method for instance storage using segment-based storage on a storage device is provided that includes storing, in a live write stream cache, one or more logical blocks corresponding to a data segment, writing, for each logical block in the data segment, a cache element of a cache entry that points to the logical block in the live write stream cache, wherein the cache entry includes multiple cache elements corresponding to the multiple logical blocks of the data segment, writing, for the cache entry, a table entry in a mapping table that points to the cache entry, and when a storage policy is triggered for the cache entry, writing the multiple logical blocks, pointed to by each cache element of the cache entry, to a stream for storing as contiguous logical blocks on the storage device, and updating the table entry to point to a physical address of a first logical block of the contiguous logical blocks on the storage device.

In another example, an apparatus for instance storage using segment-based storage on a storage device is provided where the apparatus includes a processor and a non-transitory memory with instructions thereon. The instructions upon execution by the processor, cause the processor to store, in a live write stream cache, one or more logical blocks corresponding to a data segment, write, for each logical block in the data segment, a cache element of a cache entry that points to the logical block in the live write stream cache, wherein the cache entry includes multiple cache elements corresponding to the multiple logical blocks of the data segment, write, for the cache entry, a table entry in a mapping table that points to the cache entry, and when a storage policy is triggered for the cache entry, write the multiple logical blocks, pointed to by each cache element of the cache entry, to a stream for storing as contiguous logical blocks on the storage device, and update the table entry to point to a physical address of a first logical block of the contiguous logical blocks on the storage device.

In another example, a non-transitory computer-readable storage medium storing instructions that when executed by a processor cause the processor to execute a method is provided. The method includes storing, in a live write stream cache, one or more logical blocks corresponding to a data segment, writing, for each logical block in the data segment, a cache element of a cache entry that points to the logical block in the live write stream cache, wherein the cache entry includes multiple cache elements corresponding to the multiple logical blocks of the data segment, writing, for the cache entry, a table entry in a mapping table that points to the cache entry, and when a storage policy is triggered for the cache entry, writing the multiple logical blocks, pointed to by each cache element of the cache entry, to a stream for storing as contiguous logical blocks on the storage device, and updating the table entry to point to a physical address of a first logical block of the contiguous logical blocks on the storage device.

To the accomplishment of the foregoing and related ends, the one or more implementations comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more implementations. These features are indicative, however, of but a few of the various ways in which the principles of various implementations may be employed, and this description is intended to include all such implementations and their equivalents.

In some instances, well-known components are shown in block diagram form in order to avoid obscuring such concepts.

This disclosure describes various examples related to providing segment-based storage for instance storage. Some solutions have included multiple layers L2P caching, where interface card firmware (FW) for a solid state drive (SSD) or SSD array can divide a whole L2P into several small regions, where each region is stored in NOT-AND (NAND) Flash. In such solutions, dynamic random access memory (DRAM) only can hold a second layer mapping (SLM), where each SLM entry can include a NAND physical address (NPA) of a small region. One issue may be that any access of LB can use two threads or processes: one for SLM, and one for logical block (LB). Also SLM may be dumped into NAND, which can result in write amplification (WA). SLM can be cached in DRAM and having extra logic for L2P caching check, while the management overhead is still large. This solution can be widely applied in client SSD as the access pattern of client market is localized so that cache hit rate is high.

Other solutions can include segment-based management where instead of managing mapping information on a LB size basis (e.g., <NUM> kilobyte (KB)), FW of the SSD interface card can manage logical-to-physical (L2P) mapping in larger granularity, such as <NUM> kilobyte (KB), which can reduce the size of (and thus resources used for managing) the L2P mapping table. The larger granularity collection of LBs can be referred to herein as a segment. For example, the capacity space of the SSD or SSD drive array can be divided into segments in larger granularity, such as 64KB granularity, where each L2P entry can point to the start NPA of a segment. LBs in a segment can be physically contiguous so that during read, FW of the SSD interface card can determine the physical location of each LB by using a starting NPA of the segment (e.g., a NPA of a first LB in the segment) and an offset of the LB within the segment (e.g., Start_NPA + AU_OFFSET). While a host can still access SSD in 4KB granularity, if allocation unit (AU) is not full, FW can pad the AU, which can result in times of WA. When LB in an AU is updated, FW can do read modify write (RMW) operations, which will also result in times of WA.

In accordance with aspects described herein, segment-based management can be used for instance storage, where data segments can be formed by storing associated LBs in a live write stream cache (e.g., using append-only storage) and managed in a cache entry that points to LBs associated with a given data segment. A mapping table entry for the data segment can point to the cache entry to facilitate access to the data segment while in the live write stream cache. When a storage policy is triggered, the LBs in the live write stream cache can be written to a garbage collection (GC) stream in sequential order by data segment for storage in the drive array. The mapping table can be updated to point, for each data segment stored in the GC stream, to the first LB for the data segment as stored in the GC stream. In this regard, after the storage policy is triggered, access to the data segment is provided in the GC stream, and a given LB in the data segment can be located based on the address of the first LB of the data segment, as obtained from the mapping table entry, combined with an offset of the desired LB within the data segment.

Using the segment-based storage in this regard can facilitate reducing a size of the L2P mapping table (e.g., by a factor according to the number of LBs in a segment). In addition, using the live write cache stream can allow for append-only storage, and managing the live write cache stream with cache entries facilitates ordering of the LBs written to the live write cache stream for access and subsequent storage in the drive array, which can optimize accessing the LBs as being sequentially stored.

Turning now to <FIG>, examples are depicted with reference to one or more components and one or more methods that may perform the actions or operations described herein, where components and/or actions/operations in dashed line may be optional. Although the operations described below in <FIG> and <FIG> are presented in a particular order and/or as being performed by an example component, the ordering of the actions and the components performing the actions may be varied, in some examples, depending on the implementation. Moreover, in some examples, one or more of the actions, functions, and/or described components may be performed by a specially-programmed processor, a processor executing specially-programmed software or computer-readable media, or by any other combination of a hardware component and/or a software component capable of performing the described actions or functions.

<FIG> is a schematic diagram of an example of a drive array interface <NUM> for facilitating access to a drive array <NUM> including multiple storage devices <NUM>. For example, the storage devices <NUM> can include multiple SSDs, as described, which can be combined into a single system storage. The drive array interface <NUM> can facilitate mapping the multiple storage devices <NUM> as a single system storage by including logic or algorithms to resolve a physical LB address (LBAs) to a physical LB on one of the multiple storage devices <NUM>. In one example, a physical LBA <NUM> can correspond to LB <NUM> on a first storage device, physical LBA <NUM> can correspond to LB <NUM> on a next storage device, etc., such that a physical LBA can be resolved to a storage device based on the physical LBA divided by the number of storage devices <NUM> in the drive array <NUM>, and the physical LB on the storage device that is based on the physical LBA modulo the number of storage devices <NUM> in the drive array <NUM>. This is just one specific example of combining storage devices <NUM> into a single system storage, and substantially any mechanism to combine the storage devices <NUM> is possible such that the drive array interface <NUM> can allocate physical LBAs and know how to resolve the physical LBA to the physical LB of a certain storage device in the drive array <NUM>.

In an example, drive array interface <NUM> can provide one or more applications <NUM> with access to the drive array <NUM> for storing data, retrieving stored data, updating stored data, etc. For example, drive array interface <NUM> can include a processor <NUM> and/or memory <NUM> configured to execute or store instructions or other parameters related to providing a segment-based storage component <NUM>. The processor <NUM> and/or memory <NUM> can be part of firmware on the drive array interface. In one example, drive array interface <NUM> can leverage processor <NUM> and/or memory <NUM> of a computing device that includes the drive array interface <NUM> to execute the drive array interface <NUM>, associated firmware, associated functions and/or components described herein, etc. In one example, the drive array interface <NUM> can be coupled to an interface bus on a server, and can utilize the processor <NUM> and/or memory <NUM> of the server (e.g., alone or in conjunction with additional processing or memory resources of the drive array interface <NUM>) to provide the functions and/or associated components described herein. For example, processor <NUM> and memory <NUM> may be separate components communicatively coupled by a bus (e.g., on a motherboard or other portion of a computing device, on an integrated circuit, such as a system on a chip (SoC), etc.), components integrated within one another (e.g., processor <NUM> can include the memory <NUM> as an on-board component <NUM>), and/or the like. Memory <NUM> may store instructions, parameters, data structures, etc., for use/execution by processor <NUM> to perform functions described herein.

In an example, segment-based storage component <NUM> can facilitate storing data on the drive array <NUM> in data segments that are comprised of multiple LBs, which can effectively reduce the L2P mapping table size, as described above, by a factor of the number of LBs in a data segment. In one specific example, the LBs can be 4KB and the data segment can be 64KB, such that each data segment include <NUM> LBs, and the L2P mapping table can be reduced by a factor of <NUM>. For example, segment-based storage component <NUM> can include a mapping table <NUM> for mapping NPAs of data segments to LBs on the drive array <NUM> or on the live write stream cache <NUM>, as described herein. In an example, segment-based storage component <NUM> can include one or more of the live write stream cache <NUM> for writing LBs of data segment for storage as append-only, a mapping cache <NUM> including cache entries that point to the LBs in the live write stream cache <NUM> for a given data segment, a GC stream <NUM> for storing sequential LBs for one or more data segments for storing on the drive array <NUM>, a metadata component <NUM> for storing and/or managing metadata associated with data segments stored via segment-based storage component <NUM>, and/or a compressing component <NUM> for compressing LBs for storing in the GC stream <NUM>.

<FIG> illustrates an example of storage structures <NUM> used by a segment-based storage component <NUM>, in accordance with aspects described herein. Storage structures <NUM> include representations of a mapping table <NUM>, live write stream cache <NUM>, mapping cache <NUM>, GC stream <NUM>, as described above and further herein. For example, multiple applications (e.g., applications <NUM>) can write to the drive array <NUM> for storage. Drive array interface <NUM> can allocate storage locations for the applications <NUM> that are defined in mapping table <NUM>. Drive array interface <NUM> can resolve mapping table entries in mapping table <NUM> to physical LBs of the storage devices <NUM> in the drive array <NUM>, as described. The mapping table <NUM> can accordingly maintain a list of NPAs associated with data segments. In an example, the table entries in the mapping table <NUM> can be provided back to the applications <NUM>, and each table entry can point to a NPA, which may include a physical LBA of a storage device <NUM> in the drive array <NUM>, a location in a GC stream for storage in the drive array <NUM>, a cache entry that points to a live write stream location, etc..

In an example, live write stream cache <NUM> can include LBs received from the applications <NUM> for storage, where the LBs can include LBs to be associated as data segments and as certain table entries in the mapping table <NUM>. Live write stream cache <NUM>, however, may be append-only and random read storage, such that the LBs may not be received or stored sequentially in the live write stream cache <NUM>. For example, multiple applications <NUM> can concurrently write to the drive array interface <NUM>, and as such, live write stream cache <NUM> can include scattered LBs from the multiple applications. When LBs are written to the live write stream cache <NUM>, segment-based storage component <NUM> can write a cache element of an associated cache entry to point to the live write stream cache <NUM> location of the LB, and can store, as the table entry in the mapping table <NUM> for the corresponding data segment, an address of the cache entry in the mapping cache <NUM>.

For example, the segment-based storage component <NUM> can allocate locations for storing data segments to one or more applications <NUM> in table entry X0 <NUM>, table entry X1 <NUM>, table entry X2 <NUM>, and table entry X3 <NUM>. Based on allocating the locations or otherwise on receiving LBs for the allocated data segments, segment-based storage component <NUM> can update the corresponding mapping table entries to point to cache entries in mapping cache <NUM>. For example, table entry X0 <NUM> can point to cache entry <NUM><NUM>, table entry X1 <NUM> can point to cache entry <NUM><NUM>, table entry X2 <NUM> can point to cache entry <NUM><NUM>, and table entry X3 <NUM> can point to cache entry <NUM><NUM>. As LBs are stored in live write stream cache <NUM>, as received from the applications <NUM>, the associated cache entries can be updated to have cache elements that point to the LBs in the live write stream cache <NUM>. For example, when NPA (X0, <NUM>) is stored in the live write stream cache <NUM>, segment-based storage component <NUM> can update cache entry <NUM><NUM> to include a cache element that points to NPA (X0, <NUM>) in the live write stream cache <NUM>. Similarly, when NPA (X1, <NUM>) is stored in the live write stream cache <NUM>, segment-based storage component <NUM> can update cache entry <NUM><NUM> to include a cache element that points to NPA (X1, <NUM>) in the live write stream cache <NUM>, and so on.

In this example, if an application <NUM> requests to read, update, delete, etc. LBs associated with the data segment of table entry X0 <NUM>, segment-based storage component <NUM> can obtain the cache entry pointer from the table entry X0 <NUM>, determine which cache element in the cache entry <NUM><NUM> is associated with the requested LB, and determine to which LB in the live write stream cache <NUM> the cache element points. For example, for the LB of NPA (X0, <NUM>) in the data segment of cache entry <NUM><NUM>, segment-based storage component <NUM> can obtain an indication of the LB location in the live write stream cache <NUM> from the cache element in the cache entry <NUM><NUM> for NPA (X0, <NUM>), and can obtain the LB for providing to the application <NUM>. In one example, a storage policy can be triggered, which can result in live write stream cache <NUM> LBs being written to a GC stream <NUM> for storage. Examples are shown in <FIG> and <FIG>.

<FIG> illustrates an example of storage structures <NUM> used by a segment-based storage component <NUM> in storing LBs of a data segment, in accordance with aspects described herein. Storage structures <NUM> include representations of a mapping table <NUM>, live write stream cache <NUM>, mapping cache <NUM>, GC stream <NUM>, LB metadata <NUM> stored in a metadata component <NUM>, as described above and further herein. In an example, storage structures <NUM> can be similar to storage structures <NUM> described in <FIG> above, and can include similar data as storage structures <NUM> until a storage policy for table entry X2 <NUM> is triggered. In the present invention, the storage policy is triggered when all LBs for the data segment are received in live write stream cache <NUM> or, in unclaimed embodiments, based on other triggers, such as a request to store a certain data segments, or all data segments in the live write stream cache <NUM>, or to otherwise flush the live write stream cache <NUM> and/or mapping cache <NUM>, etc..

Based on the storage policy for table entry X2 <NUM> being triggered, in an example, segment-based storage component <NUM> can read cache entry <NUM><NUM>, based on the pointer to the cache entry <NUM><NUM> in table entry X2 <NUM>. For example, segment-based storage component <NUM> can obtain the cache elements of cache entry <NUM><NUM>, each of which point to a LB location in live write stream cache <NUM> that includes an LB of the data segment (e.g., LB locations in live write stream cache <NUM> of NPA (X2, <NUM>), NPA (X2, <NUM>), NPA (X2, <NUM>), NPA (X2, <NUM>), shown in live write stream cache <NUM> <FIG> and as blank spaces in <FIG>). In an example, segment-based storage component <NUM> can flush these LBs from the live write stream cache <NUM> sequentially into LBs of the GC stream <NUM>, starting at LB <NUM>. For example, this can include writing contents of the LBs (e.g., copying or moving) from the LBs of the live write stream cache <NUM> to the LBs in the GC stream <NUM> and/or deleting the contents of the LBs in the live write stream cache <NUM> that were copied or moved.

In an example, segment-based storage component <NUM> can store the LBs sequentially to facilitate efficient access of the LBs based on the location of the starting LB and the index, which can be managed for the data segment by the drive array interface <NUM>, as described herein. In addition, when writing the LBs to the GC stream <NUM>, metadata component <NUM> can write metadata for the data segment, which can include one or more of a valid bitmap <NUM> indicating which of the LBs of the data segment have valid data, an AU index <NUM> pointing to the starting location of the first LB of the data segment, a hotness flag <NUM> indicating whether the data stored in the data segment is hot, warm, cold, etc., which can be an indication of whether the data is relatively static or dynamic, a QoS flag <NUM> indicating a QoS associated with the data stored in the data segment, etc. In addition, for example, once the LBs are flushed to the GC stream, segment-based storage component <NUM> can delete or free data from cache entry <NUM><NUM>, so the cache entry <NUM><NUM> can be reused for managing a subsequent data segment stored in live write stream cache <NUM>. In yet another example, when writing LBs to the GC stream <NUM>, compressing component <NUM> may perform compressing of the LBs to further optimize storage thereof, and the compressed LBs can be stored in the GC stream <NUM> for storing in drive array <NUM>. This may result in a lesser number of LBs stored for a given data segment.

<FIG> illustrates an example of storage structures <NUM> used by a segment-based storage component <NUM> in storing LBs of a first and a second data segment, in accordance with aspects described herein. Storage structures <NUM> include representations of a mapping table <NUM>, live write stream cache <NUM>, mapping cache <NUM>, GC stream <NUM>, LB metadata <NUM> and <NUM> stored in a metadata component <NUM>, as described above and further herein. In an example, storage structures <NUM> can be similar to storage structures <NUM> described in <FIG> above, and can include similar data as storage structures <NUM> until a storage policy for table entry X1 <NUM> is triggered (e.g., after or at the same time as the storage policy for table entry X2 <NUM>).

Based on the storage policy for table entry X1 <NUM> being triggered, in an example, segment-based storage component <NUM> can read cache entry <NUM><NUM>, based on the pointer to the cache entry <NUM><NUM> in table entry X1 <NUM>. For example, segment-based storage component <NUM> can obtain the cache elements of cache entry <NUM><NUM>, each of which point to a LB location in live write stream cache <NUM> that includes an LB of the data segment (e.g., LB locations in live write stream cache <NUM> of NPA (X1, <NUM>) and NPA (X1, <NUM>), shown in live write stream cache <NUM> <FIG> and as blank spaces in <FIG>). In an example, segment-based storage component <NUM> can flush these LBs from the live write stream cache <NUM> sequentially into LBs of the GC stream <NUM>, starting at LB <NUM>, which can be a next LB after the last LB of another data segment (e.g., the data segment represented as table entry X2 <NUM>). For example, this can include writing contents of the LBs (e.g., copying or moving) from the LBs of the live write stream cache <NUM> to the LBs in the GC stream <NUM> and/or deleting the contents of the LBs in the live write stream cache <NUM> that were copied or moved.

In an example, segment-based storage component <NUM> can store the LBs sequentially to facilitate efficient access of the LBs based on the location of the starting LB and the index, which can be managed for the data segment by the drive array interface <NUM>, as described herein. In addition, when writing the LBs to the GC stream <NUM>, metadata component <NUM> can write metadata for the data segment, which can include one or more of a valid bitmap <NUM> indicating which of the LBs of the data segment have valid data, an AU index <NUM> pointing to the starting location of the first LB of the data segment, a hotness flag <NUM> indicating whether the data stored in the data segment is relatively static or dynamic, a QoS flag <NUM> indicating a QoS associated with the data stored in the data segment, etc. For example, the valid bitmap <NUM> for NPA X2 can be '<NUM>' as all of the LBs for the data segment were written in the live write stream cache <NUM> with valid data, and the valid bitmap <NUM> for NPA X1 can be '<NUM>' as the first two LBs for the data segment were written in the live write stream cache <NUM> with valid data. In addition, for example, once the LBs are flushed to the GC stream, segment-based storage component <NUM> can delete or free data from cache entry <NUM><NUM>, so the cache entry <NUM><NUM> can be reused for managing a subsequent data segment stored in live write stream cache <NUM>.

In the examples described above and further herein, segment-based storage can include dividing the whole instance storage into segments, where a segment can represent a user space sequential LBA range. A segment can be the minimum mapping management unit. An application can in place update any user-LBA randomly and read the LBAs in any granularity. In addition, for example, the drive array space (e.g., a nonvolatile memory express (NVMe) SSD or other SSD array media space) can be divided into contiguous ranges. A zone can include an append-only write, random read area (e.g., in zoned namespace (ZNS) SSD). For NVMe Conventional SSD, the zone can include a contiguous LBA range in one SSD. Two level mapping can be provided where LBs from different segments can first write in card on LB basis, and after sealed or after flush policy is triggered, LBs can be GC to sequential LBs and write into GC stream so that mapping info can be smaller. The examples described above and further here can also use GC to collect scattered LBs of a segment into sequential so that mapping info can be smaller. Compression can also be triggered during GC - e.g., compression can be a background activity and can compress cold data. In instance storage, data can be managed as a segment, where segment can be a fixed size (64KB normally) and in place update written into SSD. On the storage card, segments can be written simultaneously, and an application can write data onto those segments in parallel. In this design, segment storage solution can be optimized for instance storage.

In an example, mapping table <NUM> can include, for each data segment, a segment index, which can be the table index, the entry of the segment table is the location of the segment data in the drive array <NUM> (or can be resolved to the drive array <NUM>, as described above). For example, each table entry, as described, can point to either a mapping cache <NUM> cache entry or an NPA, which includes a NPA of the first (e.g., starting) LB of the segment. In the mapping table <NUM>, each entry may specify a segment state (e.g., trimmed, caching, unsealed, sealed, as described further herein), and/or a segment entry, which may depend on the segment state. For example, for caching state, the segment state can include an index in the mapping cache <NUM> of the cache entry that corresponds to the data segment. For unsealed and sealed state, the segment state can include the first valid LB's NPA of an AU. For trimmed state, the segment state can include the trimmed type including all 0b1 trim, all 0b0 trim, deterministic pattern trim, error report trim, unwritten, write unc, write zero for each LB. In this example, the segment state can be the state of the whole segment. For example, if partial segment is trimmed, the segment state is not trimmed. The GC process can help remove the trimmed LBs in a segment.

In an example, mapping cache <NUM> can include, for each cache entry, one or more of NPAs for LBs of an unsealed segment (unsealed can indicate that the whole data segment is not fully written), a segment index indicating the associated AU index (e.g., table entry index in the mapping table <NUM>) of the cache entry, and/or a Next Ptr, which can be a pointer to manage the cache entries for cache policy.

The segment metadata generated for each data segment by the metadata component <NUM> (e.g., when the segment is moved to GC stream <NUM>), such as metadata <NUM> and/or metadata <NUM>, can be stored together with segment data onto NAND. The segment metadata can include one or more of a data segment index (e.g., the table entry index for sanity check and recovery), a valid bitmap to indicate which LBs in a data segment are valid, a QoS Flag that can be used by the storage policy (e.g., GC policy) to determine when to trigger storage, a hotness flag, which can be application assigned and used by the storage policy (e.g., GC policy) to determine when to trigger storage. In an example, a valid bitmap table can be referred for unsealed data segment accessing, where each bit represents the NPA associated with LB offset in the data segment, where <NUM> can indicate the associated LB is unwritten, <NUM> can indicate the associated LB is written or vice versa. A valid 0b1 count can match the LB count of a data segment stored in segment metadata. By using start_NPA and valid bitmap, for example, the NPA for each valid LB in the AU can be determined. This data structure can be stored in DRAM or not. If valid bitmap is stored in DRAM, it can be used to find the requested LB's NPA. If valid bitmap is not stored in DRAM, the drive array interface <NUM> FW can read maximum LB count starting from start_NPA and then use valid bitmap stored in segment metadata to figure out the requested LB's NPA, which may cause extra read amplification.

<FIG> illustrates an example of a state machine <NUM> for a segment mapping table <NUM> entry in accordance with aspects described herein. State machine <NUM> includes a trimmed state <NUM>, a caching state <NUM>, an unsealed state <NUM>, and a sealed state <NUM> corresponding to a mapping table entry.

For example, in the trimmed state <NUM>, the segment mapping table entry state, which can be used to mark the data segment, is unwritten. Each LB in this data segment's specific state can be specified in the state array. LB state can be: unwritten, write UNC, trimmed with <NUM> pattern, trimmed with deterministic pattern, trimmed with error report required. For example, in the caching state <NUM>, the data segment can be cached in RAM or live write stream cache <NUM>, and its associated LBs mapping info can be stored in mapping cache <NUM> entry. The drive array interface <NUM> (or corresponding FW) can refer to mapping cache <NUM> for cache state.

For example, in the unsealed state <NUM>, when Segment is not fully written, drive array interface <NUM> (or corresponding FW) may consolidate it to GC stream <NUM> to release cache entry or release live write stream cache <NUM> or associated zone. The AU mapping table <NUM> entry can be in unseal state.

For example, in the sealed state <NUM>, when the data segment is fully written, drive array interface <NUM> (or corresponding FW) can consolidate the AU to GC stream <NUM>. This can be triggered when live write stream cache <NUM> is full, or mapping cache <NUM> is full, for example.

A given mapping table entry can start in the trimmed (unwritten) state <NUM>. When an application or host first writes LBs to a data segment, the data segment states switch from trimmed to caching state <NUM>. For example, the drive array interface <NUM> (or corresponding FW) can allocate a cache entry in the mapping cache <NUM> for the data segment and points the mapping table entry to that cache entry.

When LB mapping cache is full, the cache entry can be retired. If the data segment is fully written, drive array interface <NUM> (or corresponding FW) can consolidate the data segment to GC stream <NUM> and switch the data segment mapping state to sealed state <NUM>. If the data segment is partially written, the AU state can be in the unsealed state <NUM>. One difference between the sealed state <NUM> and the unsealed state <NUM> can be that for sealed state <NUM>, by using start NPA, LB offset and bad block table, drive array interface <NUM> (or corresponding FW) can calculate any LBs in the data segment. For unsealed state <NUM>, as there may be holes (e.g., unwritten LBs) in the consolidated data segment, drive array interface <NUM> (or corresponding FW) can obtain the valid bitmap for the data segment and can calculate the NPA of LB in the data segment. For example, compression can be applied during GC so that after GC, segment size might be smaller than <NUM> LBs (64KB), a <NUM> bits length bit can be used to store the compressed length, or 64KB can be read, but there may be a tradeoff between memory size and read amplification.

Sealed state <NUM> can switch to trimmed state <NUM> in some cases, such as if all LBs in a data segment become invalid. If partial data segment is trimmed or updated, the data segment can switch to caching state <NUM> with valid bitmap updated. RMW can be triggered to consolidate the data segment again. Unsealed state <NUM> can switch to trimmed state <NUM> if all LBs in the data segment become invalid. If partial data segment is trimmed or updated, the data segment can switch to caching state <NUM> with valid bitmap updated. RMW may be triggered to consolidate the data segment again. Decompression can be involved during RMW process.

<FIG> illustrates an example of a state machine <NUM> for a mapping cache <NUM> cache entry in accordance with aspects described herein. State machine <NUM> includes an idle state <NUM>, a RAM state <NUM>, and a live stream state <NUM>. The cache entry can start from IDLE state <NUM>, where LBs of a data segment can be first placed in RAM with associated buffer slot ID. After allocating by segment mapping table manager of the drive array interface <NUM> (or corresponding FW) or other process, the cache entry in the mapping cache <NUM> can be associated with a data segment (e.g., associated with a table entry in the mapping table <NUM>).

The AU can be cached in the RAM state <NUM>. In the RAM state <NUM>, the LB's buffer slot ID can be placed into a cache element of the cache entry in the mapping cache <NUM> (e.g., into LB mapping info cache entry of the data segment). In this state, data of LBs of the data segment can be in RAM. When RAM cache is full, if segment is fully written, drive array interface <NUM> (or corresponding FW) can GC the data segment to GC stream, and the cache entry (or corresponding cache elements in the cache entry) can be released. If the data segment is not fully written, drive array interface <NUM> (or corresponding FW) can write the partial data segment into live write stream cache <NUM>.

In the live stream state <NUM>, segment data can be cached in live write stream cache <NUM>. When the live write stream cache is full or the cache entry for the data segment (e.g., LB mapping info cache) is full, drive array interface <NUM> (or corresponding FW) can GC the data segment from live write stream cache to the GC stream <NUM> so that cache entry can switch to IDLE state <NUM> and release the cache entry information and/or corresponding cache elements.

The segment mapping table <NUM> and the mapping cache <NUM> can be mapping info that can be flushed onto NAND. A valid bitmap table can be used, or can be recovered after power on in background. Before valid bitmap is fully recovered, read amplification can occur by reading max for unsealed data segment, as described above.

In reference to the data segment states and writing LBs as described above, for open data segment write, segment-based storage component <NUM> can allocate a mapping cache <NUM> cache entry for append. When the data segment is sealed, segment-based storage component <NUM> can use a recycle engine to relocate LBs of a data segment to GC stream <NUM>, and compressing component <NUM> may perform compression of the LBs during GC. After GC, segment data can be physically contiguous so segment-based storage component <NUM> can replace the table entry for the data segment (in mapping table <NUM>) to point to the NPA of the data segment in the GC stream <NUM> or drive array <NUM>, rather than the mapping cache <NUM> cache entry index. When mapping cache <NUM> is full, cache retire policy (weighted LRU) can be applied to release cache entries. In this case, even unsealed AUs can be recycled to GC stream <NUM>. As some of LBs in an segment may be unwritten, valid bitmap can be accordingly updated, as described herein (e.g., to avoid padding the unwritten LBs with dummy data). Written LBs can be recycled into GC stream <NUM>, and the mapping table <NUM> entry for the data segment can be updated to point to the NPA of the first valid LB of the data segment. During a read operation, for example, the requested LB can be located based on the first LB pointed to by the mapping table <NUM> entry and/or an offset of the requested LB.

<FIG> is a flowchart of an example of a method <NUM> for writing data segments in a segment-based storage for instance storage. For example, method <NUM> can be performed by a drive array interface <NUM> and/or one or more components thereof for storing data segments in a drive array <NUM>.

In method <NUM>, at action <NUM>, one or more LBs corresponding to a data segment can be stored in a live write stream cache. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can store, in the live write stream cache <NUM>, the one or more LBs correspond to the data segment. For example, one or more applications <NUM>, which may be executing on a same or different computing device as the drive array interface <NUM>, may request storage of data via the drive array interface <NUM>. In this example, segment-based storage component <NUM> can determine to store the data in data segments, which can be larger in size than LBs of the storage devices <NUM> in the drive array <NUM> (and can comprise multiple LBs, as described herein). In one example, based on receiving a request for storage, drive array interface <NUM> can provide the application(s) <NUM> with a corresponding NPA used for, or otherwise associated with, storing the data segment. As described, the NPA can correspond to, or can be resolved to, an index of an entry in the mapping table <NUM>.

In method <NUM>, at action <NUM>, a cache element of a cache entry that points to the LB in the live write stream cache can be written for each LB in the data segment. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can write, for each LB in the data segment, the cache element of the cache entry that points to the LB in the live write stream cache <NUM>. For example, when segment-based storage component <NUM> stores an LB in the live write stream cache <NUM>, it can determine to which data segment the LB belongs, which may be identified by a process requesting storage of the LB, an identifier in the LB, etc. In an example, segment-based storage component <NUM> can obtain the cache entry pointer from the mapping table <NUM> entry for the data segment, and can populate a cache element corresponding to the LB with an index into the live write stream cache <NUM> for the LB. For example, referring to <FIG>, when LB for NPA (X1, <NUM>) is stored in live write stream cache <NUM>, segment-based storage component <NUM> can update the second cache element of cache entry <NUM><NUM> with the location in live write stream cache <NUM> of the LB for NPA (X1, <NUM>).

In method <NUM>, at action <NUM>, a table entry in a mapping table that points to the cache entry can be written for the cache entry. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can write, for the cache entry, the table entry in the mapping table that points to the cache entry. For example, segment-based storage component <NUM> can write the table entry to point to the cache entry for all cache entries in the mapping cache <NUM> that have cache elements pointing to LBs in the live write stream cache <NUM>. In one example, segment-based storage component <NUM> can write the table entries as pointers into the mapping cache <NUM> based on providing a table entry identifier to an application <NUM> for a data segment to be stored, or based on receiving a first LB for the data segment in the live write stream cache <NUM>, etc. For example, referring to <FIG>, segment-based storage component <NUM> can write the table entry <NUM><NUM> to point to cache entry <NUM><NUM> in the mapping cache <NUM>. This process can continue for multiple LBs received in the live write stream cache <NUM>.

At some point in time, at action <NUM>, a storage policy trigger can be detected. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can detect the storage policy trigger. For example, the storage policy trigger may correspond to a specific data segment, or to the live write stream cache <NUM> in general, as described. In one example, the storage policy can related to, or be triggered by, filling all LBs allocated (or indicated a cache elements in the cache entry) for a data segment. In any case, based on detecting the storage policy trigger at action <NUM>, at action <NUM>, multiple LBs, pointed to be each cache element of the cache entry, can be written to a stream for storing as contiguous LBs on a storage device. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can write the multiple LBs, pointed to by each cache element of the cache entry, to the stream (e.g., GC stream <NUM>) for storing as contiguous LBs on a storage device (e.g., a storage device <NUM> of drive array <NUM>). For example, at least a portion of the multiple LBs associated with a cache entry may be in non-contiguous locations in the live write stream cache <NUM>, and segment-based storage component <NUM> can write the multiple logical blocks, associated with the cache entry, from the live write stream cache <NUM> in a sequence corresponding to the order of the multiple cache elements as specified in the corresponding cache entry, as shown and described in reference to <FIG> and <FIG> above.

In one example, the storage policy may include or otherwise be defined to free up cache entry and/or zones (referred to as Policy <NUM>). For example, the storage policy can include GCing a zone with least valid LB in the live write stream cache <NUM>. In another example, the storage policy can include GCing sealed data segments to prevent future RMW (referred to as Policy <NUM>). If unsealed data segment is triggered because of running out of caches, segment-based storage component <NUM> can select the data segment with most LBs or the oldest unsealed data segment for GC (referred to as Policy <NUM>). The foregoing policy inputs can be considered. When the drive array interface <NUM> determines critical capacity pressure state, the policies may be given weight for considering in performing GC (e.g., Policy <NUM> can have the highest weight). When the drive array interface <NUM> determines no critical capacity pressure, the policies (e.g., Policy <NUM>, Policy <NUM>, and Policy <NUM>) can be considered using a weighted scoring scheme.

Based on the contiguous storage, for example, the data segment can be access by storing only a NPA of a first LB, as described herein, which can conserve space in the L2P table. Accordingly, at action <NUM>, the table entry can be updated to point to a NPA of a first LB of the contiguous LBs on the storage device. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can update the table entry (e.g., in the mapping table <NUM>) of the data segment to point to the NPA of the first LB of the contiguous LBs on the storage device (e.g., instead of to the cache entry).

In method <NUM>, optionally at action <NUM>, data segment metadata can be updated based on storing the contiguous LBs. In an example, metadata component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can update data segment metadata for the data segment based on storing the contiguous LBs. For example, as described, metadata component <NUM> can update a valid bitmap to indicate which LBs in the data segment have valid data, can update a AU index to point to the table entry in the mapping table <NUM>, can update a hotness flag or QoS flag based on application-specified parameters for the data stored in the data segment, etc. Metadata component <NUM> can update metadata for the data segment at other points in the process as well.

For example, in writing the cache element at action <NUM>, optionally at action <NUM>, data segment metadata can be updated based on writing the cache element. In an example, metadata component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can update data segment metadata for the data segment based on writing the cache element. For example, as described, metadata component <NUM> can update a valid bitmap to indicate the LB corresponding to the cache element as having valid data. In other examples, metadata component <NUM> can update the data segment metadata when the table entry of the mapping table <NUM> is associated with the cache entry in the mapping cache <NUM>. This update may include updating the AU index to point back to the mapping table <NUM> table entry, the hotness flag or QoS flag based on application-specified parameters for the data, etc..

In one example, in writing the multiple LBs to the stream for storing as contiguous LBs at action <NUM>, optionally at action <NUM>, compression of at least a portion of the LBs can be performed. In an example, compressing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can perform compression of at least a portion of the LBs. In one example, performing compression may be based on the hotness or QoS flag. For example, "cold" data that does not change very often can be compressed to save space, which may outweigh inefficiency that may be caused by having to infrequently decompress the data for reading (or modification or deletion, etc.).

In accordance with the above described storage schemes, the drive array interface <NUM> can include multiple layers of media for storing data. For example, drive array interface <NUM> can include SRAM/DRAM, which can be volatile memory that can be flushed when power loss happens so that the size cannot be large (e.g., 8MB). In an example, host write LBs can be flushed, and GC data may not need to be flushed in SRAM. In addition, drive array interface <NUM> can include data in the live write stream cache <NUM>, which can include NAND media used to hold up live write data segments. For example, after SRAM buffer is full, data can be flushed to live write stream cache <NUM> if the Segment is not sealed. As this stream is used to hold incoming write data for data segment consolidation, data on it can be considered hot so that single-level cell (SLC)/multi-level cell (MLC) mode can be used, which can lower WA and improve performance. AU may not need to be consolidated immediately after sealing, for hot data segment, if it is deleted before consolidating it to GC stream, this data segment may not be written to GC stream. In addition, drive array interface <NUM> can include the GC stream <NUM>, where a consolidated data segment can be written onto this stream. Data segments on this stream can be relatively cold so that quad-level cell (QLC) can be used to store GC stream, or triple-level cell (TLC) can be used for GC stream, and another cold stream can be used for cold data, which can be in QLC mode. In addition, drive array interface <NUM> can include a cold stream, which can be a QLC stream that uses QLC mode to store cold data.

<FIG> is a flowchart of an example of a method <NUM> for processing data segments stored in a segment-based storage for instance storage. For example, method <NUM> can be performed by a drive array interface <NUM> and/or one or more components thereof for processing data segments stored in a drive array <NUM>.

In method <NUM>, at action <NUM>, a segment index can be calculated based on a requested LBA and segment size. In an example, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can calculate the segment index based on the requested LBA and segment size. For example, this can be in response to a request to process a data segment stored in the instance storage. For example, the request can correspond to reading the data segment or a LB thereof, updating the data segment or a LB thereof, modifying the data segment or a LB thereof, deleting a data segment or a LB thereof, etc. In any case, a requested LBA can be specified, which can include a starting LB index and/or an offset. In an example, segment-based storage component <NUM> can determine the segment index of the data segment in the mapping table <NUM> based on the requested LBA and the segment size (e.g., the number of LBs in a segment).

After locating the segment, at action <NUM>, the segment state can be determined. In an example, metadata component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can determine the segment state. For example, segment-based storage component <NUM> can obtain the metadata for the data segment, which can include the segment state, as described above.

For example, where the segment state is cached, optionally at action <NUM>, a cache entry index can be obtained and NPA of the requested LBA can be determined from the cache entry. In an example, for data segments in the cached state, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can obtain the cache entry index from the table entry for the data segment index in the mapping table <NUM>, and can determine the NPA of the requested LBA based on determining the cache element for the requested LBA in the cache entry in the mapping cache <NUM>. For example, the NPA may point to the live write stream cache <NUM> in this example. Once the data is obtained, at action <NUM>, the LB stored at the NPA of the requested LBA can be processed. In an example, for data segments in the cached state, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can process the LB stored at the NPA of the requested LBA.

For example, where the segment state is unsealed, optionally at action <NUM>, a valid bitmap and a starting NPA of the data segment can be obtained and NPA of the requested LBA can be determined at the starting NPA and based on the valid bitmap. In an example, for data segments in the unsealed state, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can obtain the valid bitmap from metadata and the starting NPA from the table entry in the mapping table <NUM> for the data segment. Based on the valid bit index, for example, segment-based storage component <NUM> can map the requested LBA to a valid LB in the data segment, and can obtain the LB for processing at action <NUM>.

In one example, optionally at action <NUM>, the data segment can be decompressed at the starting NPA before processing. In an example, for compressed data segments, compressing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can decompress the data segment starting at the NPA, and then can process the LB indicated by the requested LBA from the decompressed data.

For example, where the segment state is sealed, optionally at action <NUM>, a starting NPA of the data segment can be obtained from the mapping table and NPA of the requested LBA can be determined. In an example, for data segments in the sealed state, segment-based storage component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can obtain the starting NPA from the mapping table, as the data segment is completely contiguously stored, and can determine the NPA of the requested LBA starting at the starting NPA. For example, segment-based storage component <NUM> can map the requested LBA to the LB in the data segment, which may be based on an offset of the LB in the data segment, and can obtain the LB for processing at action <NUM>.

<FIG> illustrates an example of device <NUM>, including additional optional component details as those shown in <FIG>. In one implementation, device <NUM> may include processor <NUM>, which may be similar to processor <NUM> for carrying out processing functions associated with one or more of components and functions described herein. Processor <NUM> can include a single or multiple set of processors or multi-core processors. Moreover, processor <NUM> can be implemented as an integrated processing system and/or a distributed processing system.

Device <NUM> may further include memory <NUM>, which may be similar to memory <NUM> such as for storing local versions of applications being executed by processor <NUM>, such as drive array interface <NUM>, etc. Memory <NUM> can include a type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof.

Further, device <NUM> may include a communications module <NUM> that provides for establishing and maintaining communications with one or more other devices, parties, entities, etc., utilizing hardware, software, and services as described herein. Communications module <NUM> may carry communications between modules on device <NUM>, as well as between device <NUM> and external devices, such as devices located across a communications network and/or devices serially or locally connected to device <NUM>. For example, communications module <NUM> may include one or more buses, and may further include transmit chain modules and receive chain modules associated with a wireless or wired transmitter and receiver, respectively, operable for interfacing with external devices.

Additionally, device <NUM> may include a data store <NUM>, which can be any suitable combination of hardware and/or software, that provides for mass storage of information, databases, and programs employed in connection with implementations described herein. For example, data store <NUM> may be or may include a data repository for applications and/or related parameters (e.g., drive array interface <NUM>, etc.) not currently being executed by processor <NUM>. In addition, data store <NUM> may be a data repository for drive array interface <NUM>, such as a drive array <NUM>, one or more storage devices <NUM>, etc., and/or one or more other modules of the device <NUM>.

Device <NUM> may include a user interface module <NUM> operable to receive inputs from a user of device <NUM> and further operable to generate outputs for presentation to the user. User interface module <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a navigation key, a function key, a microphone, a voice recognition component, a gesture recognition component, a depth sensor, a gaze tracking sensor, a switch/button, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface module <NUM> may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

Accordingly, in one or more implementations, one or more of the functions described may be implemented in hardware, software, firmware, or any combination thereof. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Claim 1:
A computer-implemented method for instance storage using segment-based storage on a storage device, comprising:
storing (<NUM>), in a live write stream cache (<NUM>), one or more logical blocks corresponding to a data segment, the live write stream cache (<NUM>) including scattered logical blocks from the multiple applications;
writing (<NUM>), for each logical block in the data segment, a cache element of a cache entry (<NUM>; <NUM>; <NUM>; <NUM>) that points to the logical block in the live write stream cache (<NUM>), wherein the cache entry (<NUM>; <NUM>; <NUM>; <NUM>) includes multiple cache elements corresponding to the multiple logical blocks of the data segment;
writing (<NUM>), for the cache entry (<NUM>; <NUM>; <NUM>; <NUM>), a table entry (<NUM>; <NUM>; <NUM>; <NUM>) in a mapping table (<NUM>) that points to the cache entry (<NUM>; <NUM>; <NUM>; <NUM>); and
wherein, when a storage policy is triggered for the cache entry (<NUM>; <NUM>; <NUM>; <NUM>) in response to all of the multiple logical blocks of the data segment being received in the live write stream cache (<NUM>):
writing (<NUM>) the multiple logical blocks, pointed to by each cache element of the cache entry (<NUM>; <NUM>; <NUM>; <NUM>), to a stream (<NUM>) for storing as contiguous logical blocks on the storage device (<NUM>); and
updating (<NUM>) the table entry (<NUM>; <NUM>; <NUM>; <NUM>) to point to a physical address of a first logical block of the contiguous logical blocks on the storage device.