File system-aware solid-state storage management system

• US 8,738,846 B2
• Filed: 10/14/2011
• Issued: 05/27/2014
• Est. Priority Date: 10/15/2010
• Status: Expired due to Fees

• Current Assignee: Arkologic Limited
• Original Assignee: Arkologic Limited
• Inventors: Son, Kyquang, Lee, Ronald, Lau, Henry C., Ananthanarayanan, Rajesh
• Primary Examiner(s): Bragdon, Reginald
• Assistant Examiner(s): Namazi, Mehdi
• Application Number:
  US13/274,277
• Publication Number:
  US 20120096217A1
• Time in Patent Office: 956 Days
• Field of Search: 707/813, 711/103, 711/E12.008
• US Class Current: 711/103
• CPC Class Codes: G06F 12/0246 in block erasable memory, e.g. flash memory
• CPC Class Codes: G06F 16/1847 specifically adapted to static storage, e.g. adapted to flash memory or SSD
• CPC Class Codes: G06F 2212/7201 Logical to physical mapping or translation of blocks or pages
• CPC Class Codes: G06F 3/061 Improving I/O performance
• CPC Class Codes: G06F 3/0616 in relation to life time, e.g. increasing Mean Time Between Failures [MTBF]
• CPC Class Codes: G06F 3/064 Management of blocks
• CPC Class Codes: G06F 3/0643 Management of files
• CPC Class Codes: G06F 3/0661 Format or protocol conversion arrangements
• CPC Class Codes: G06F 3/0688 Non-volatile semiconductor memory arrays

Abstract

A file system-aware SSD management system including an SSD management module that incorporates both file system information and information related to the underlying physical solid-state storage media into its operations is described. Also described are related methods for performing data management operations in a file system-aware manner. By incorporating both file system and physical storage information, the system may achieve various advantages over conventional systems, such as enhanced I/O performance, simplified SSD firmware, and extended SSD lifespan. Moreover, by moving solid-state management functions above the firmware level, the system may enable the simultaneous management of a pool of multiple SSDs.

Claims

1. A storage system comprising:

solid-state memory configured to store data persistently;

a controller, coupled to the solid-state memory, that is configured to execute firmware in order to read, program, and erase physical portions of the solid-state memory, the controller associating each different physical portion of the solid-state memory with a different physical logical block address (PLBA); and

a management module configured to;

receive a first input-output request generated by a file system, the file system organizing units of user data and metadata by associating each unit of user data or metadata in the file system with a file system logical block address (FLBA), the first request including an indication of an FLBA associated with a particular unit of data that is a subject of the first request;

translate the indicated FLBA into a PLBA associated with a particular physical portion of the solid-state memory; and

transmit a second input-output request to the controller via a device driver, the second request including an indication of the PLBA in order to indicate which physical portion of the solid-state memory the controller should read, program, or erase in order to fulfill the first request.

2. The system of claim 1, wherein the first request includes an indication of a data type of the particular unit of data that is a subject of the first request and the management module translates the included FLBA into the PLBA based at least in part on the indicated data type.

3. The system of claim 2, wherein the indication of a data type of the particular unit of data indicates whether the unit of data is metadata, user data, or raw data.

4. The system of claim 1, wherein the controller and firmware do not include garbage collection logic or wear leveling logic.

5. The system of claim 1, wherein the solid-state memory is organized into multiple superblocks, each superblock further comprises multiple superpages, each superpage further comprises multiple pages, and a PLBA comprises a combination of a superblock address, a superpage address, and a page address.

6. The system of claim 5, wherein the controller erases physical portions of the solid-state memory by erasing all data in an entire superblock, and programs a physical portion of the solid-state memory by programming all data in an entire page.

7. The system of claim 5, wherein at least some pages in the solid-state memory each comprise:

a storage space region that stores user data, metadata, or raw data; and

a data integrity field header region that stores restoration data useable to permit the management module to reconstruct at least portions of management data structures used by the management module.

8. The system of claim 7, wherein the restoration data comprises a PLBA, an FLBA, and an indicator of a time when the first input-output request was received.

9. The system of claim 1, wherein the file system is a ZFS file system.

10. The system of claim 1, wherein the solid-state memory is NAND flash memory.

11. The system of claim 1, wherein the solid-state memory is one of the following:

flash memory, magnetoresistive random access memory (MRAM), phase-change memory (i.e., PCM, PRAM, PCRAM, Ovonic Unified Memory, Chalcogenide RAM, or C-RAM), ferroelectric random access memory (FeRAM or FRAM), conductive-bridging RAM or programmable metallization cell memory, Silicon-Oxide-Nitride-Oxide-Silicon (SONOS) memory, resistive random access memory (RRAM), Racetrack Memory, Nano-RAM (NRAM), Millipede memory, dynamic random access memory (DRAM), static random access memory (SRAM), thyristor random access memory (T-RAM), zero capacitor random access memory (Z-RAM), or twin transistor random access memory (TTRAM).

12. The system of claim 1, further comprising one or more additional solid-state memories, wherein the management module is configured to perform data management operations for all of the multiple solid-state memories in the system.

13. A method for performing a write operation to a solid-state drive (SSD) having solid-state memory, the method comprising the steps of:

receiving a request from a file system to perform an operation to write source data to an SSD, the received request including an indication of a file system logical block address (FLBA) associated with the source data in the file system and a data type of the source data;

identifying superblocks in the SSD that are available as candidate superblocks to store the source data;

selecting a candidate superblock to store at least some of the source data in order to fulfill the requested operation, the selection being based at least on the data type of the source data;

determining a physical logical block address (PLBA) associated with a target physical location within the selected superblock; and

sending, via a device driver, a write request to the SSD to write the source data at the target physical location.

14. The method of claim 13, further comprising:

determining restoration data, the restoration data including the determined PLBA, a logical write position indicator, a timestamp indicating an approximate time when the write request was received, and the indicated FLBA; and

sending the determined restoration data within the write request to the SSD, the write request indicating that the SSD should write the restoration data in a data integrity field header region at the target physical location.

15. The method of claim 13, wherein the selection of a candidate superblock is also based on at least of one the following factors:

a data type of data already stored in each candidate superblock;

a wear count of each candidate superblock;

a last modification time of each candidate superblock; and

a physical layout of the solid-state memory in the SSD.

16. The method of claim 13, wherein the selection of a candidate superblock gives preference to candidate superblocks that are currently storing data of the same data type as the source data.

17. The method of claim 13, wherein selecting a candidate superblock comprises removing from consideration any candidate superblocks that are already storing a different type of data than the data type of the source data.

18. The method of claim 13, wherein the selection of a candidate superblock gives preference to candidate superblocks having lower wear counts as compared to other candidate superblocks.

19. The method of claim 13, wherein the selection of a candidate superblock is based on a determination of which candidate superblocks offer a faster write time as compared to other superblocks.

20. The method of claim 13, wherein selecting a candidate superblock comprises removing any candidate superblocks that are being used to fulfill another in-progress or pending input-output request.

21. The method of claim 13, wherein selecting a candidate superblock comprises evaluating whether a physical layout of the solid-state memory causes some candidate superblocks to have a faster write time than other candidate superblocks.

22. The method of claim 13, further comprising updating a mapping table to associate in the table the indicated FLBA with the determined PLBA.

23. The method of claim 13, further comprising updating a page status table to indicate a relative position of a page associated with the determined PLBA within a logical write operation.

24. The method of claim 13, further comprising updating, in a superblock table, at least two of the following values that are associated with the selected superblock in the table:

a superblock state, a valid page count, an invalid page count, a next superpage, next page, a stored data type, and a last modification time.

25. The method of claim 13, further comprising:

receiving a first read request from a file system to perform an operation to read data from the SSD, the received request including an indication of an FLBA associated with target data in the file system;

using the indicated FLBA as a lookup into a mapping table in order to identify a corresponding PLBA for the read request;

sending a second read request, including the identified PLBA, to the SSD via a device driver;

in response to sending the second read request, receiving a copy of the target data associated with the corresponding PLBA; and

providing the copy of the target data to the file system in response to the first read request.

26. The method of claim 13, further comprising:

initiating a deletion operation associated with a particular FLBA;

calculating a PLBA associated with the particular FLBA using a mapping table;

indicating in the mapping table that the particular FLBA is no longer associated with the calculated PLBA; and

updating management data structures to reflect that a page associated with the calculated PLBA is invalid.

27. The method of claim 26, wherein the initiation is triggered by detecting a file system block release whereby the file system moves the particular FLBA to the file system'"'"'s free storage pool.

28. The method of claim 26, wherein the initiation is triggered by receiving an explicit command from the file system to mark a page associated with the particular FLBA as invalid.

29. A method for restoring one or more management data structures used by a solid-state drive (SSD) management module, the method comprising the steps of:

receiving a request from a file system to perform an operation to write source data to an SSD, the received request including an indication of a file system logical block address (FLBA) associated with the source data in the file system;

selecting a superblock to store at least some of the source data in order to fulfill the requested operation;

determining a physical logical block address (PLBA) associated with a target page within the selected superblock;

determining restoration data, the restoration data including a combination of at least the determined PLBA, a logical write position indicator, a timestamp indicating an approximate time the request was received, and the indicated FLBA;

sending, via a device driver, a write request to the SSD to write the source data at a storage space region of the target page and to write the restoration data into a data integrity field header region of the target page;

encountering a read error when attempting to read a portion of a management data structure from the SSD;

reading the determined restoration data from the data integrity field header region at the target page, including reading the combination of the determined PLBA and indicated FLBA; and

analyzing the restoration data from the data integrity field header region to reconstruct at least some of the management data structure.

30. The method of claim 29, wherein analyzing the restoration data from the data integrity field header region to reconstruct at least some of the management data structure comprises determining if the combination of the determined PLBA and indicated FLBA is present in a mapping table.

31. The method of claim 29, wherein analyzing the restoration data from the data integrity field header region to reconstruct at least some of the management data structure comprises determining if the target page is valid based on an analysis of the timestamp.

32. A method for wear leveling a solid-state drive (SSD), the method comprising:

selecting a worn superblock at least on the basis of a comparison of a wear count of the worn superblock to wear counts of other superblocks;

selecting as a target superblock a free superblock from an over-provisioning pool;

selecting a fresh superblock on the basis of at least two of the following factors;

a wear count of the fresh superblock, a data type of data stored in the fresh superblock, and a last modification time of the fresh superblock;

copying contents of the worn superblock to the target superblock;

erasing the worn superblock;

copying contents of the fresh superblock to the worn superblock;

erasing the fresh superblock;

copying contents of the target superblock to the fresh superblock; and

erasing the target superblock.

33. The method of claim 32, wherein selecting a fresh superblock comprises selecting a superblock that satisfies at least two of the following criteria:

the superblock has a wear count that is less than a predetermined percentage of a maximum wear count for the SSD, the superblock stores user data, and the superblock has a last modification time falling within a predetermined time period.

34. The method of claim 32 wherein selecting a worn superblock is made at least on the basis of the worn superblock having a higher wear count as compared to other superblocks, and one or more of the following factors:

free page count of the worn superblock, valid page count of the worn superblock, invalid page count of the worn superblock, last modification time of the worn superblock, and a data type of data stored in the worn superblock.

35. The method of claim 32 wherein selecting a worn superblock is made at least on the basis of the worn superblock having a highest wear count as compared to other superblocks.

36. The method of claim 32, further comprising:

determining whether one or more superblocks have a wear count above a predetermined threshold value; and

performing the other steps in the method when one or more superblocks have a wear count above a predetermined threshold value, otherwise not performing the other steps.

37. The method of claim 32, further comprising performing a garbage collection process.

38. The method of claim 32, wherein during at least one of the following steps garbage collection is performed so that invalid pages are not copied:

copying contents of the worn superblock to the target superblock,

copying contents of the fresh superblock to the worn superblock, and

copying the contents of the target superblock to the fresh superblock.

39. The method of claim 32, further comprising:

determining a difference between a wear count of the target superblock and a wear count of the fresh superblock;

when the difference exceeds a predetermined threshold, performing the steps of;

copying contents of the fresh superblock to the worn superblock;

erasing the fresh superblock;

copying contents of the target superblock to the fresh superblock; and

erasing the target superblock;

otherwise, when the difference does not exceed the predetermined threshold, not performing these four steps.

40. One or more computer memories collectively storing a page status data structure comprising multiple entries, each entry representing a current status of a single page of data stored in solid-state memory, each entry for a page comprising:

a logical write position indicator for the page that indicates a relative position of the page within a larger logical write operation requested by a file system, indicating whether the page was a starting page, a middle page, or an end page of the logical write operation; and

a page status indicator for the page that indicates whether the page has not been programmed since it was last erased, the page contains valid data that is still in use, or the page contains invalid data that is stale;

such that the contents of the page status data structure are useable to identify an invalid page that may be reclaimed during a garbage collection operation.

41. The one or more computer memories of claim 40, wherein the page status data structure is organized as a bitmap.

42. One or more computer memories collectively storing a mapping data structure comprising multiple entries, each entry representing physical addressing information for a unit of data associated with a particular file system logical block address (FLBA) used by a file system to address the unit of data, each entry for a unit of data comprising:

a data type indicator for the unit of data that indicates whether the unit of data is a unit of metadata, user data or raw data;

a superblock address indicating a superblock that physically stores the unit of data, the superblock forming a portion of a solid-state memory;

a superpage address indicating a superpage that physically stores the unit of data, the superpage forming a portion of the superblock;

a page address indicating a page that physically stores the unit of data, the page forming a portion of the superpage; and

such that the contents of the mapping data structure are useable to identify a physical location for a unit of data in response to an input-output request.

43. The one or more computer memories of claim 42, wherein the mapping data structure is organized as a hash table.

44. The one or more computer memories of claim 42, wherein each entry for a unit of data further comprises a sector address indicating a sector that physically stores the unit of data, the sector forming a portion of the page.

45. One or more computer memories collectively storing a superblock data structure comprising multiple entries, each entry representing a current status of a superblock of data stored in solid-state memory, each entry for a superblock comprising:

a wear count that indicates how many times the superblock has been erased;

a valid page count and an invalid page count that indicate how many pages within the superblock are valid and invalid, respectively;

an indication of a physical location of a next page within the superblock that is available for writing new data;

a last modification time that indicates approximately the most recent time at which any page within the superblock was invalidated or programmed; and

a data type indicator that indicates whether the superblock stores metadata, user data or raw data;

such that the contents of the superblock data structure are useable to identify superblocks useable to perform a garbage collection operation, wear leveling operation, or input-output operation.