Technology to manage capacity loss in storage drives

A system including a storage drive and a semiconductor apparatus coupled to the storage drive, is provided. The semiconductor apparatus may include one or more substrates and logic coupled to the one or more substrates, the logic coupled to the one or more substrates to: initiate managing resources of the storage drive and, if the storage drive loses capacity, determine an amount of capacity loss, create a reserved file that is associated with logical memory space in a file system, based on the amount of the capacity loss, and erase at least a portion of the reserved file so that logical memory space associated with an un-erased portion of the reserved file is usable by the storage drive.

TECHNICAL FIELD

Embodiments generally relate to storage drives such as, for example, a solid-state drive (SSD), hard drive, etc. More particularly, embodiments relate to managing capacity loss of a storage drive over time.

BACKGROUND

Storage drives may encounter problems related to loss of available capacity. The capacity of some storage drives may decrease over time.

SSDs, for example, contain NAND flash memory, the fundamental unit of which is typically a 4 kilobyte (KB) page. In SSDs, data writes may occur one page at a time, but only on blank (erased) pages. Pages may not be directly overwritten, rather they must first be erased. When a host wants to rewrite data to an address of a NAND of an SSD, the SSD writes to a different, blank page and then updates a logical block address (LBA) table. Inside the LBA table, the original page is marked as “invalid” and the new page is marked as the current location for the new data. Overprovisioning is employed to reserve extra space to account for the above-described write operations and the concomitant loss of available SSD capacity (e.g., NAND capacity) that occurs over time.

DESCRIPTION OF EMBODIMENTS

Because of memory shrinking capacity issues, memory and computing device vendors may overprovision storage drive (e.g., SSD) capacity in order to provide better write performance and higher endurance. That is, such vendors routinely advertise significantly more memory capacity for their SSDs than they actually make available for a host device (also referred to as “host”). Therefore, SSDs typically have additional hidden capacity, which usually equals 5%-100% of the capacity exposed to the host. This hidden capacity increases the available “ready to be written” resource pool, which decreases write amplification—for example, due to the nature of NAND Flash Memories in that a block in the NAND must be erased before new data can be written to the NAND block, extra NAND operations may be required to move data stored in the SSD more than once. This extra movement of data may involve erases and writes to accommodate a host write request. These extra NAND write operations create a multiplying effect producing an “amplification” effect; thus, the term, “write amplification”. By overprovisioning as described above, since there is less background data movement, performance and endurance increases. The instant disclosure and exemplary embodiments thereof may produce an exemplary result of decreasing the required amount of additional memory to a smaller percent of the exposed capacity (i.e., lessen or completely remove the need for overprovisioning).

Another issue with SSDs is that, in the manufacturing process of SSDs, all NAND dies placed in a particular SSD are checked to determine if they work correctly. If one or more NAND dies have lower capacity than desired, they are discarded in post-production process. This approach may result in a waste of NAND flash memory. The exemplary solutions described below may reduce the necessity to discard NAND dies that have lower capacity than desired since the instant solution manages the capacity loss of a SSD.

Additionally, sometimes NAND dies are organized in packages. If at least one NAND die in a package is damaged, the entire package may be discarded because all NAND dies of a particular SSD model may be required have the same capacity. Thus, if one NAND die does not have the exact same capacity as other NAND dies in a package, the entire package may have to be discarded. Exemplary solutions as described below may also reduce the necessity to discard an entire package of NAND dies because the NAND dies in the package do not have the exact same capacity.

According to exemplary embodiments of the instant disclosure, SSDs with different capacity may be used, so NAND dies with lower capacity than expected may still be able to be used in the SSD and would not need to be discarded.

Also, an aspect of the instant disclosure may advantageously affect cold storage approaches of SSDs, such that SSD-data is not frequently invalidated and such that SSDs that are managed according to the exemplary embodiments may have a very low overprovisioning ratio. Cold storage is a term related to storing data that is infrequently accessed. That is, cold storage may refer to data that was written some time ago and not read for a long time. The advantageous results may be achieved by way of exemplary embodiments that involve an SSD with shrinking capacity and host-based software, where the host-based software handles capacity loss events deriving from the SSD. Such software may be designed and implemented to operate with existing file systems without any modifications in the file systems. For example, when an SSD notifies host-based software about a capacity change, the host-based software may algorithmically shrink the available capacity of the SSD by a requested capacity. An SSD may notify the host system over a storage interface, such as, for example, Non-volatile Memory Express (NVMe) or Serial Advanced Technology Attachment (SATA), and by using input/output (IO) control codes on the operating system side of the host system.

Advantages of the instant disclosure may include, but are not limited to, enabling software to work with new types of SSDs (with shrinking capacity), not requiring application changes, and the ability to shrink the capacity of SSDs such that the cost of SSDs is decreased, which may increase profit margins on the sale of SSDs. Thus, the entire capacity of an SSD may include the space available for use and other internal space (e.g., memory used for garbage collection in the SSD).

Turning now toFIG. 1, a memory management system150is shown. The memory management system150may be a single computing device or system which includes a manager application151, a file system (FS) partition153and an SSD155, which includes, for example, NAND memory devices for storage. The manager application151may also be implemented via logic coupled to one or more substrates of a semiconductor apparatus, a manager application server and/or a computing device (not shown). The manager application151may alternatively be implemented over a network remote from the memory resources that are being managed. In memory management system150, SSD firmware may have the ability to increase memory space which is hidden from the operating system (OS). The firmware may be applied, for example, via the manager application151of the memory management system150or, alternatively, applied from a remote location. Such may be necessary in the event that: 1) a NAND Erase or NAND Program command does not succeed, 2) a particular NAND block is discarded, and 3) there is a need to use another NAND block.

According to an exemplary embodiment as reflected inFIG. 1, software may be implemented via the manager application151to manage Capacity Loss Events of an SSD155. In the memory management system150ofFIG. 1, software may use Capacity Loss Units291(FIGS. 2A and 2B) to manage Capacity Loss Events. As shown inFIG. 2B, the size of the Capacity Loss Unit291may correspond, for example, to a particular amount of data loss that would alert a system to a Capacity Loss Event. A Capacity Loss Unit is a fixed size unit expressed in logical block address space in memory of the SSD—in other words, a capacity loss may relate to a loss of logical memory space. A Capacity Loss Unit may be deallocated (e.g., “trimmed”). “Trim” may mean, for example, to erase at least a portion of or the entire Capacity Loss Unit. For example, a Capacity Loss Unit may be a logical representation of a data block to be at least partially erased via an algorithm, rather than a physical block of data. The algorithm itself may divide, e.g., a filename system namespace of an SSD into Capacity Loss Units.

According to an exemplary embodiment, an SSD290(FIG. 2B) may be equally divided into a predetermined or specific number of Capacity Loss Units291. Each Capacity Loss Unit291may have the same size. Alternatively, there may be an SSD according to a different exemplary embodiment, with very small Capacity Loss Units of different size, where the amount of Capacity Loss is determined based on the number of lost Capacity Loss Units.

FIG. 2Aillustrates communications between a host system281and an SSD280. The SSD280may include a controller285which manages an interface for communicating with the host system281and the non-volatile memory devices286(e.g., NANDs), which constitute the SSD280. InFIG. 2A, Capacity Loss Units may be illustrated as part of a file system namespace, where there may be actual files (e.g., two files, File 1 and File 2) and a Capacity Loss Unit.

According to an exemplary embodiment, software, via a manager application151, may use input/output control codes to exchange information with the SSD. Alternatively, SATA and NVMe commands may be used to exchange information with the SSD. The following operations are possible via the exchange of information with the SSD: 1) Read Capacity Loss Unit Size; 2) Read Capacity Loss Units, which means the overall number of already lost capacity may be expressed in Capacity Loss Units; and 3) Register for Asynchronous Capacity Loss Event. According to an exemplary embodiment, asynchronous events may be those events occurring independently of a main program flow.

According to an exemplary embodiment, software, via a manager application151, may also use file system application programming interfaces (APIs) to create Reserved Files. A Reserved File is a file created by the software to allocate space in a file system. Reserved Files may be managed only by the software according to exemplary embodiments. A file system API may also be used to inform the solid-state drive which blocks of data inside a Reserved File are no longer in use and can be erased internally. The file system API may also initiate the operation of wiping or erasing the data. For example, one or more of the operations of informing the SSD or initiating the erasing of data, as described above, may be performed by way of a TRIM command (issued by a host to the SSD).

According to an exemplary embodiment, a software-based algorithm for managing memory resources of an SSD may include an Initialization Flow and a Capacity Loss Flow. An Initialization Flow may relate to an initialization that is performed once an SSD is discovered in a system. Such an Initialization Flow is also applicable when a new partition is created on an SSD or in a computing system having an SSD. An initialization process may include reading several parameters from an SSD to set up the algorithm.

A Capacity Loss Flow according to an exemplary embodiment may include a process that is performed when an SSD reports a Capacity Loss (e.g., memory capacity loss). Software implemented via manager application151may consume lost space by creating a new Reserved File to match the loss in memory capacity. The memory/NAND blocks associated with this new Reserved File may then be entirely erased or at least partially erased so that the memory associated with that file can still be used by the SSD. That is, at least a portion of the memory/NAND blocks associated with the Reserved File may be erased so that logical memory associated with an un-erased portion of the file is usable by the storage drive. Such memory space may be determined by a host and may be referred to as ‘free space’ or ‘deallocated memory space’. In other words, the loss in memory capacity may be reflected as logically consumed space in the file system, not physically consumed space in the SSD.

FIG. 3illustrates a sequence diagram of a method300for managing memory resources of an SSD according to an exemplary embodiment. The sequence flow shows example illustrations of the Initialization Flow330and Capacity Loss Flow340, which are described above. The Initialization Flow330is the initial process necessary to determine the capacity of an SSD with respect to its Capacity Loss Units and the Capacity Loss Flow340is the flow that is executed when a drive notifies software about a Capacity Loss.

InFIG. 3, during an Initialization Flow330, operation331shows a manager application301reading a Capacity Loss Unit Size of the SSD303. As an optional feature, prior to, during, or after operation331, a Victims File List (not shown) may be provided. A Victims File List may include a sacrificial list of files that may be deleted if capacity begins to run out (e.g., when no more Reserved Files can be created because all of the logical capacity in the file system has been used). In operation333, the Capacity Loss Unit Size may be obtained from the SSD and stored.

As an alternative to reading the Capacity Loss Unit Size, a manager application may request a Capacity Loss Size from an SSD controller (e.g., element285inFIG. 2A) and the requested Capacity Loss Unit Size may be returned from the SSD controller.

In operation335, the manager application301may read the number of Capacity Loss Units of the SSD303. In operation337, the number of Capacity Loss Units may be obtained from the SSD303. As an alternative operation, the manager application301may request the number of Capacity Loss Units from an SSD controller and the requested the number of Capacity Loss Units may be returned from the SSD controller.

In an exemplary embodiment, the manager application301may calculate already Reserved Space, which is a sum of the Usable Size of each Reserved File on a partition, where Usable Size of a Reserved File is a sum of all Capacity Loss Units that fit into particular Reserved file.

In operation339, a manager application301may check if previously Reserved Space on the file system is greater than, less than, or equal to Capacity Loss Units. If previously Reserved Space on the file system is greater than or equal to Capacity Loss Units, then initialization is complete; otherwise additional Reserved File capacity has to be reserved in the Capacity Loss Flow340part of the method of managing memory resources300.

FIG. 3also shows a Capacity Loss Flow340. During Capacity Loss Flow340, capacity loss detection may be a background process that involves detecting a Capacity Loss Event from a drive (e.g., SSD). This background process may include reserving space on the file system by creating Reserved Files. Reserved Files may be created to use up the amount of capacity that has failed in the SSD, but they do not consume actual (good) physical blocks of memory in the SSD. That is, Reserved Files may be used to represent logical space in the file system, which cannot be used by a user. Reserved Files do not actually occupy any physical blocks of memory in the SSD.

To reserve space on the file system by creating Reserved Files, software implemented via the manager application301according to an exemplary embodiment may erase at least a portion of all blocks in the Reserved Files after creating them. This erase operation ensures that the Reserved Files consume only failed memory space that is assigned to logical memory space in the file system.

WhileFIG. 3only shows operations of a Capacity Loss Flow loop345at a high level (i.e., 1. Use File System API to retrieve necessary data, 2. Report Number of Reserved Units, 3. Register for Asynchronous Capacity Loss Event, etc.), according to an exemplary embodiment, if a Capacity Loss Event occurs, the following Capacity Loss flow operations may occur:

1. Read Capacity Loss Units from the SSD.

2. Calculate Required Capacity value—it is the difference between current Capacity Loss Units value and the previous value, expressed in bytes.

3. Check free space (unused space) on the file system—if free space on the file system is greater or equal than Required Capacity value, then go to operation 7 below.

4. Select candidate file(s) to be removed (e.g., from Victim File list)—algorithm may pick the file(s) based on the closest match of the size of the file.

5. Delete selected file(s) from the file system.

6. Disable any FS defragmentation for the new Reserved File that is about to be created.

7. Create the new Reserved File of size equal to the Required Capacity value.

8. Read physical Reserved File placement from the file system—in general, the Reserved File may be placed in multiple locations (sub-regions) in memory in a SSD, for example.

9. Find all Capacity Loss Units (e.g., those which fit into the Reserved File).

10. Calculate Usable Size of the Reserved File, which means the sum of the sizes of all detected Capacity Loss Units.

11. If the calculated Usable Size is lower than the Required Capacity value, then set a new Required Capacity value based on a subtraction of Usable Size from the Required Capacity, and proceed to operation 3 above.

12. For each Capacity Loss Unit, send a command to at least partially erase the Capacity Loss Unit, to SSD.

13. Register for new Asynchronous Capacity Loss Event

Operations 1-13 above may be performed within a Capacity Loss loop345.

FIG. 4shows a method of managing memory resources of a SSD according to an exemplary embodiment. The method50may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc., in configurable logic such as, for example, programmable logic arrays (PLAs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), in fixed-functionality hardware logic using circuit technology such as, for example, application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof.

Illustrated processing block52provides for initializing, by a manager application, an initialization flow to manage memory resources of an SSD. Additionally, if the SSD loses capacity, block54provides for determining the amount of capacity loss, block56provides for creating a new reserved file based on the capacity loss, and block58provides for erasing at least a portion of the new reserved file so that memory space associated with the new reserved file is used by the SSD.

Turning now toFIGS. 5-7, these figures illustrate block diagrams of SSDs during example processes of managing memory resources in an SSD. The sizes, amounts, and numbers used in these embodiments are merely examples and may vary. According to an exemplary embodiment, an SSD may be inserted into a system. A 1 GB partition may be created within a file system on the SSD. A manager application may begin an initialization process, which may include: a) a Victim File List (defined above) not being provided; 2) reading a Capacity Loss Unit Size; and 3) reading the number of Capacity Loss Units. According to this exemplary embodiment, the SSD reports that the Capacity Loss Unit Size is 64 KB and the number of Capacity Loss Units is two (2). In the initialization process if no Reserved Files are found, there is a need to create at least one Reserved File to allocate memory for two (2) Capacity Loss Units. The manager application may then proceed to handle a first Capacity Loss.

In the process of handling two (2) Capacity Loss Units, it may be determined that the Required Capacity is 2*64 KiB=128 KiB. There is 1 GiB of unused space on the file system, which is greater than 128 KiB, so the software may proceed to operation 7 of the Capacity Loss Flow, as described above. Operation 7 of the Capacity Loss Flow reads, “Create the new Reserved File of size equal to the Required Capacity value”.

Thus, a new Reserved File610inFIG. 6of 128 KiB may be created. This new Reserved File610may be created in a special directory (e.g., Reserved/Reserved0001.file or in a root directory). The new Reserved File610may be placed in one sub-region of SSD600ofFIG. 6, where the Byte Offset is 0 and the size of the Reserved File610is 128 KiB. Two Capacity Loss Units620are reserved via the new Reserved File610.

According to the exemplary embodiment, the usable size of the new Reserved File610may be calculated. The usable size of the Reserved File610may be 128 KiB, which is the same size as the Required Capacity value, so the software proceeds to a new operation.

A command to at least partially erase Capacity Loss Units, may be sent to the two (2) first Capacity Loss Units620inFIG. 6, and the manager application may register for a new asynchronous Capacity Loss Event to detect any future losses in capacity. That is, a manager application may register itself to be notified when a Capacity Loss Event occurs.

In a subsequent operation according to an exemplary embodiment, an SSD may send a Capacity Loss Event, which the manager application may then manage. Accordingly, Capacity Loss Units may then be read based on the subsequent operation. In the subsequent operation, an SSD may report, for example, six (6) Capacity Loss Units. Since previous Capacity Loss Units were reported as two (2), the Required Capacity value is equal to (6−2)*64 KiB=256 KiB. The software of the manager application may then read unused space on the file system. In this example, the unused space is 100 MiB, so the software may proceed to operation 7 of the Capacity Loss Flow, as described above, since the amount of file system unused space is greater than the than the Required Capacity value.

Similar to above, new Reserved Files710(FIG. 7), totaling 256 KiB may be created. The new Reserved Files710may be placed in two sub-regions of the SSD700. The Byte Offset for one Reserved File may be 131072 (128 KiB) and 270336 for the other.

According to the exemplary embodiment represented byFIG. 7, only three (3) whole Capacity Loss Units720are part of the Reserved Files710—the third, fourth, and sixth Capacity Loss Units720.

Usable Size of the Capacity Loss Units720may be equal to 3*64 KiB=192 KiB, which is less than the Required Capacity value of 256 KiB—so the software may proceed to operation 3 of the Capacity Loss Flow (above) with a new Required Capacity value, which is 256 KiB−192 KiB=64 KiB. Operation 3 involves checking free space (unused space) on the file system.

Software implemented via a manager application may read unused space on the file system as approximately 99.8 MiB, so the software may proceed to operation 7 of the Capacity Loss Flow algorithm (above). A new Reserved File730of 64 KiB may be created in, for example, a special directory (e.g., Reserved/Reserved0003.file). The new Reserved File may be physically allocated to one particular sub-region of an SSD700(FIG. 7), where the Byte Offset is 458752 and the size is 64 KiB. Next, a Usable Size of the new Reserved File730may be calculated.

InFIGS. 5-7, the Usable Size may be the number of bytes that are aligned with a Capacity Loss Unit. It may be determined that a Usable Size of the Reserved File730is equal to 64 KiB. The manager application may determine whether the calculated Usable Size of the Reserved File730is the same as the Required Capacity value, and if so the manager application may proceed to the next operation. A command to at least partially erase Capacity Loss Units, may be sent to the 3rd, 4th, 6th, and 8thCapacity Loss Units, which are in their entirety part of Reserved Files of the SSD. The manager application may then register for a new asynchronous Capacity Loss Event, which may be performed by sending a command to the SSD.

Turning now toFIG. 8, an exemplary system70having a storage drive (e.g., mass storage90) is shown. The system70may generally be part of an electronic device/platform having computing functionality (e.g., personal digital assistant/PDA, notebook computer, tablet computer, convertible tablet, server), communications functionality (e.g., smart phone), imaging functionality (e.g., camera, camcorder), media playing functionality (e.g., smart television/TV), wearable functionality (e.g., watch, eyewear, headwear, footwear, jewelry), vehicular functionality (e.g., car, truck, motorcycle), robotic functionality (e.g., autonomous robot), etc., or any combination thereof. In the illustrated example, the system70includes one or more processors72(e.g., host processor(s), central processing unit(s)/CPU(s)) having one or more cores74and an integrated memory controller (IMC)76that is coupled to a system memory78.

The illustrated system70also includes an input output (TO) module80implemented together with the processor(s)72on a semiconductor die82as a system on chip (SoC), wherein the IO module80functions as a host device and may communicate with, for example, a display84(e.g., touch screen, liquid crystal display/LCD, light emitting diode/LED display), a network controller86(e.g., wired and/or wireless), and mass storage90(e.g., hard disk drive/HDD, optical disk, solid state drive/SSD, flash memory). The processor(s)72may execute instructions92retrieved from the system memory78and/or the mass storage90via a manager application to perform one or more aspects of the method50(FIG. 4).

The mass storage90contains a memory structure that may include either volatile memory or non-volatile memory. Non-volatile memory is a storage medium that does not require power to maintain the state of data stored by the medium. In one embodiment, the memory structure is a block addressable storage device, such as those based on NAND or NOR technologies. A storage device may also include future generation nonvolatile devices, such as a three-dimensional (3D) crosspoint memory device, or other byte addressable write-in-place nonvolatile memory devices. In one embodiment, the storage device may be or may include memory devices that use silicon-oxide-nitride-oxide-silicon (SONOS) memory, electrically erasable programmable read-only memory (EEPROM), chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level Phase Change Memory (PCM), a resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), anti-ferroelectric memory, magnetoresistive random access memory (MRAM) memory that incorporates memristor technology, resistive memory including the metal oxide base, the oxygen vacancy base and the conductive bridge Random Access Memory (CB-RAM), or spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a DW (Domain Wall) and SOT (Spin Orbit Transfer) based device, a thyristor based memory device, or a combination of any of the above, or other memory. The storage device may refer to the die itself and/or to a packaged memory product. In some embodiments, 3D crosspoint memory may comprise a transistor-less stackable cross point architecture in which memory cells sit at the intersection of word lines and bit lines and are individually addressable and in which bit storage is based on a change in bulk resistance. In particular embodiments, a memory module with non-volatile memory may comply with one or more standards promulgated by the Joint Electron Device Engineering Council (JEDEC), such as JESD218, JESD219, JESD220-1, JESD223B, JESD223-1, or other suitable standard (the JEDEC standards cited herein are available at jedec.org).

Volatile memory is a storage medium that requires power to maintain the state of data stored by the medium. Examples of volatile memory may include various types of random access memory (RAM), such as dynamic random access memory (DRAM) or static random access memory (SRAM). One particular type of DRAM that may be used in a memory module is synchronous dynamic random access memory (SDRAM). In particular embodiments, DRAM of the memory modules complies with a standard promulgated by JEDEC, such as JESD79F for Double Data Rate (DDR) SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, or JESD79-4A for DDR4 SDRAM (these standards are available at jedec.org). Such standards (and similar standards) may be referred to as DDR-based standards and communication interfaces of the storage devices that implement such standards may be referred to as DDR-based interfaces.

Thus, execution of the instructions92may cause the system70to initialize, by a manager application, an initialization flow to manage memory resources of an SSD, and if the SSD loses capacity, determine the amount of capacity loss, create a new reserved file based on the capacity loss, and at least partially erase the new reserved file so that memory space associated with the new reserved file is used by the SSD.

FIG. 9shows a semiconductor package apparatus100. The apparatus100may be readily substituted for the semiconductor die82(FIG. 8), already discussed. The illustrated apparatus100includes one or more substrates102(e.g., silicon, sapphire, gallium arsenide) and logic104(e.g., transistor array and other integrated circuit/IC components) coupled to the substrate(s)102. The logic104may be implemented at least partly in configurable logic or fixed-functionality hardware logic. The illustrated logic104includes a manager application106. The logic104may generally implement one or more aspects of the method50(FIG. 4). Accordingly, the logic104may initialize, by the manager application106, an initialization flow to manage memory resources of an SSD, and if the SSD loses capacity, determine the amount of capacity loss, create a new reserved file based on the capacity loss, and at least partially erase the new reserved file so that memory space associated with the new reserved file is used by the SSD.

In one example, the logic104includes transistor channel regions that are positioned (e.g., embedded) within the substrate(s)102. Thus, the interface between the logic104and the substrate(s)102may not be an abrupt junction. The logic104may also be considered to include an epitaxial layer that is grown on an initial wafer of the substrate(s)102.

FIG. 10also illustrates a memory270coupled to the processor core200. The memory270may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. The memory270may include one or more code213instruction(s) to be executed by the processor core200, wherein the code213may implement the method50(FIG. 4), already discussed. The processor core200follows a program sequence of instructions indicated by the code213. Each instruction may enter a front end portion210and be processed by one or more decoders220. The decoder220may generate as its output a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals which reflect the original code instruction. The illustrated front end portion210also includes register renaming logic225and scheduling logic230, which generally allocate resources and queue the operation corresponding to the convert instruction for execution.

Although not illustrated inFIG. 10, a processing element may include other elements on chip with the processor core200. For example, a processing element may include memory control logic along with the processor core200. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches.

Referring now toFIG. 11, shown is a block diagram of a computing system1000embodiment in accordance with an embodiment. Shown inFIG. 11is a multiprocessor system1000that includes a first processing element1070and a second processing element1080. While two processing elements1070and1080are shown, it is to be understood that an embodiment of the system1000may also include only one such processing element.

Each processing element1070,1080may include at least one shared cache1896a,1896b. The shared cache1896a,1896bmay store data (e.g., instructions) that are utilized by one or more components of the processor, such as the cores1074a,1074band1084a,1084b, respectively. For example, the shared cache1896a,1896bmay locally cache data stored in a memory1032,1034for faster access by components of the processor. In one or more embodiments, the shared cache1896a,1896bmay include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.

As shown inFIG. 11, various I/O devices1014(e.g., biometric scanners, speakers, cameras, sensors) may be coupled to the first bus1016, along with a bus bridge1018which may couple the first bus1016to a second bus1020. In one embodiment, the second bus1020may be a low pin count (LPC) bus. Various devices may be coupled to the second bus1020including, for example, a keyboard/mouse1012, communication device(s)1026, and a data storage unit1019such as a disk drive or other mass storage device which may include code1030, in one embodiment. The illustrated code1030may implement the method50(FIG. 4), already discussed, and may be similar to the code213(FIG. 10), already discussed. Further, an audio I/O1024may be coupled to second bus1020and a battery1010may supply power to the computing system1000.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture ofFIG. 11, a system may implement a multi-drop bus or another such communication topology. Also, the elements ofFIG. 11may alternatively be partitioned using more or fewer integrated chips than shown inFIG. 11.

Additional Notes and Examples:

Example 1 may include a system comprising a storage drive, a semiconductor apparatus coupled to the storage drive, the semiconductor apparatus including one or more substrates and logic coupled to the one or more substrates, the logic coupled to the one or more substrates to: determine an amount of capacity loss of the storage drive; create a file that is associated with logical memory space in a file system, based on the amount of the capacity loss; and erase at least a portion of the file so that logical memory space associated with an un-erased portion of the file is usable by the storage drive.

Example 2 may include the system of Example 1, wherein the amount of capacity loss relates to loss of logical memory space, and wherein an initialization flow to manage resources in the storage drive is to be triggered when the storage drive is discovered in the system.

Example 3 may include the system of Example 1, wherein an initialization flow to manage resources in the storage drive is to be triggered when a new partition is created.

Example 4 may include the system of Example 1, wherein the SSD is a solid-state drive.

Example 5 may include the system of Example 1, wherein the logic coupled to the one or more substrates is to read a capacity loss unit size, and read a number of capacity loss units to trigger an initialization flow.

Example 6 may include the system of any one of Examples 1 to 5, wherein, if the storage drive loses capacity, the logic coupled to the one or more substrates further is to register for a new capacity loss event.

Example 7 may include a semiconductor apparatus comprising one or more substrates, and logic coupled to the one or more substrates, wherein the logic is implemented at least partly in one or more of configurable logic or fixed-functionality hardware logic, the logic coupled to the one or more substrates to determine an amount of capacity loss of a storage drive, create a file that is associated with logical memory space in a file system, based on the amount of capacity loss, and erase at least a portion of the file so that logical memory space associated with an un-erased portion of the file is usable by the storage drive.

Example 8 may include the apparatus of Example 7, wherein the amount of capacity loss relates to loss of logical memory space, and wherein an initialization flow to manage resources is to be triggered when the storage drive is discovered in a system.

Example 9 may include the apparatus of Example 7, wherein an initialization flow to manage resources is to be triggered when a new partition is created.

Example 10 may include the apparatus of Example 7, wherein the storage drive is a solid-state drive.

Example 11 may include the apparatus of Example 7, wherein the logic coupled to the one or more substrates is to read a capacity loss unit size, and read a number of capacity loss units to trigger an initialization flow.

Example 12 may include the apparatus of any one of Examples 7 to 11, wherein, if the storage drive loses capacity, the logic coupled to the one or more substrates further is to register for a new capacity loss event.

Example 13 may include at least one computer readable storage medium comprising a set of instructions, which when executed by a computing system, cause the computing system to determine an amount of capacity loss of a storage drive, create a file that is associated with logical memory space in a file system, based on the amount of capacity loss, and erase at least a portion of the file so that logical memory space associated with an un-erased portion of the file is usable by the storage drive.

Example 14 may include the least one computer readable storage medium of Example 14, wherein the amount of capacity loss relates to loss of logical memory space, and wherein an initialization flow to manage resources of the storage drive is to be triggered when the storage drive is discovered in a system.

Example 15 may include the least one computer readable storage medium of Example 13, an initialization flow to manage resources of the storage drive is to be triggered when a new partition is created.

Example 16 may include the least one computer readable storage medium of Example 13, wherein the storage drive is a solid-state drive.

Example 17 may include the least one computer readable storage medium of Example 13, wherein the set of instructions, when executed, cause the computing system to read a capacity loss unit size, and read a number of capacity loss units to trigger an initialization flow.

Example 18 may include the least one computer readable storage medium of any one of Examples 13 to 17, wherein the set of instructions, when executed, further cause the computing system to, if the storage drive loses capacity, register for a new capacity loss event.

Example 19 may include a method comprising determining an amount of capacity loss of a storage drive, creating a file that is associated with logical memory space in a file system, based on an amount of capacity loss, and erasing at least a portion of the file so that logical memory space associated with an un-erased portion of the file is usable by the storage drive.

Example 20 may include the method of Example 19, wherein the amount of capacity loss relates to loss of logical memory space, and wherein an initialization flow is to be triggered when the storage drive is discovered in a system.