US2022129420A1PendingUtilityA1

Method for facilitating recovery from crash of solid-state storage device, method of data synchronization, computer system, and solid-state storage device

Assignee: UNIV NAT TSING HUAPriority: Feb 23, 2019Filed: Jan 10, 2022Published: Apr 28, 2022
Est. expiryFeb 23, 2039(~12.6 yrs left)· nominal 20-yr term from priority
G06F 2212/2022G06F 3/0659G06F 3/0617G06F 16/178G06F 2212/7201G06F 3/0679G06F 2212/1032G06F 3/061G06F 12/0875G06F 12/1009G06F 12/0804G06F 3/0619G06F 2212/452
54
PatentIndex Score
0
Cited by
0
References
0
Claims

Abstract

A method for facilitating recovery from a crash of a solid-state storage device (SSD) is adapted to be implemented by an SSD controller of the SSD that receives a write request. The method includes: assigning a write request identifier (WID) and a request size in a spare area of each written page of the SSD; counting a number of appearances of the WID in all written page(s) to result in a WID count; determining whether the WID count is equal to the request size; and determining that the write request is completed and is eligible for recovery after a crash of the SSD when it is determined that the WID count is equal to the request size.

Claims

exact text as granted — not AI-modified
What is claimed is: 
     
         1 . A method of data synchronization, to be implemented by a computer system that includes a computing apparatus executing an application software and data management software and including a main memory, and that includes a solid-state storage device (SSD) communicable with the computing apparatus, the method comprising:
 issuing, by the application software, to the data management software an instruction of synchronization for synchronizing the main memory and the SSD; and   by the data management software in response to receipt of the instruction of synchronization, issuing a command to transfer a journal to the SSD, and issuing a command to transfer a commit record to the SSD immediately subsequent to issuing the command to transfer the journal.   
     
     
         2 . The method of data synchronization as claimed in  claim 1 , further comprising:
 by the data management software in response to receipt of the instruction for synchronization, issuing a flush request immediately subsequent to issuing the command to transfer the commit record.   
     
     
         3 . The method of data synchronization as claimed in  claim 2 , the method further comprising:
 issuing, by the application software to the data management software, an instruction of barrier-only synchronization for synchronizing the main memory and the SSD; and   by the data management software in response to receipt of the instruction of barrier-only synchronization, issuing a command to transfer a journal to the SSD, and issuing a command to transfer a commit record to the SSD immediately subsequent to issuing the command to transfer the journal.   
     
     
         4 . The method of data synchronization as claimed in  claim 3 , the SSD including a nonvolatile memory and an SSD controller, the nonvolatile memory including a plurality of pages each of which has a spare area, the SSD controller receiving from a host a write request to write data in at least one of the pages, the method further comprising a procedure for facilitating recovery from a crash of the SSD, the procedure includes:
 assigning, by the SSD controller according to an order in which the write request was received, a write request identifier (WID) in the spare area of each of at least one written page that is written with the data, where the WID is a unique sequence number for the write request;   assigning, by the SSD controller, a request size in the spare area of each of the at least one written page, where the request size indicates a total number of the at least one of the pages in which the write request is to write the data;   counting, by the SSD controller, a number of appearances of the WID in the at least one written page to result in a WID count;   determining, by the SSD controller, whether the WID count is equal to the request size; and   determining, by the SSD controller, that the write request is completed and is eligible for recovery after a crash of the SSD when it is determined that the WID count is equal to the request size.   
     
     
         5 . The method of data synchronization as claimed in  claim 1 , wherein the data management software is a filesystem. 
     
     
         6 . The method of data synchronization as claimed in  claim 1 , further comprising:
 sending, by the data management software, a query to the SSD; and   receiving, by the data management software from the SSD, an indicator responding to the query and indicating that the SSD is in a mode that the SSD refraining from making commit record durable until the SSD determines that the journal is durable.   
     
     
         7 . The method of data synchronization as claimed in  claim 1 , wherein in the step of issuing a command to transfer a commit record to the SSD, the command to transfer a commit record is issued without being succeeded by a flush request. 
     
     
         8 . A method for facilitating recovery from a crash of a solid-state storage device (SSD), the SSD including a nonvolatile memory and an SSD controller, the nonvolatile memory including a plurality of pages each of which has a spare area, the SSD controller receiving from a host a write request to write data in at least one of the pages, the method comprising:
 assigning, by the SSD controller according to an order in which the write request was received, a write request identifier (WID) in the spare area of each of at least one written page that is written with the data, where the WID is a unique sequence number for the write request;   assigning, by the SSD controller, a request size in the spare area of each of the at least one written page, where the request size indicates a total number of the at least one of the pages in which the write request is to write the data;   counting, by the SSD controller, a number of appearances of the WID in the at least one written page to result in a WID count;   determining, by the SSD controller, whether the WID count is equal to the request size; and   determining, by the SSD controller, that the write request is completed and is eligible for recovery after a crash of the SSD when it is determined that the WID count is equal to the request size.   
     
     
         9 . The method for facilitating recovery from a crash as claimed in  claim 8 , the SSD further including a write cache, the SSD controller further receiving a prior write request and a later write request both of which are to be coalesced in the write cache, the method comprising:
 by the SSD controller for each of the coalesced pages used to cache data corresponding to the prior write request and coalesced with the cache pages corresponding to the later write request, recording a page-coalescing record which contains the WID of the prior write request, the request size corresponding to the prior write request, and a WID of the later write request;   counting, by the SSD controller, a number of appearances of the WID of the prior write request in at least one written page that is written with data of the prior write request to result in a WID count for the prior write request;   counting, by the SSD controller, a number of appearances of the WID of the prior write request in the page-coalescing records for the coalesced pages to result in a page-coalescing count corresponding to the prior write request;   determining, by the SSD controller, whether a sum of the WID count for the prior write request and the page-coalescing count corresponding to the prior write request is smaller than the request size corresponding to the prior write request; and   determining, by the SSD controller, that the prior write request is incomplete and is ineligible for recovery after a crash of the SSD when it is determined that the sum of the WID count for the prior write request and the page-coalescing count corresponding to the prior write request is smaller than the page size requested by the prior write request.   
     
     
         10 . The method for facilitating recovery from a crash as claimed in  claim 9 , the method further comprising:
 by the SSD controller for each of cache pages in the write cache used to cache data corresponding to the prior write request, tagging the cache page with a dirty flag, a WID tag and a size tag, where the dirty flag indicates whether the cache page is a coalesced page which is coalesced with a cache page used to cache data corresponding to the later write request, the WID tag stores a WID of the prior write request, and the size tag stores a request size which indicates a total number of pages in which the prior write request is to write the data.   
     
     
         11 . The method for facilitating recovery from a crash as claimed in  claim 8 , the SSD controller further receiving a prior write request and a later write request, the method further comprising:
 refraining, by the SSD controller, from making the later write request durable until it is determined that the prior write request is durable.   
     
     
         12 . The method for facilitating recovery from a crash as claimed in  claim 11 , further comprising:
 transmitting, by the SSD controller in response to receipt of a query, an indicator indicating that the SSD controller is in a mode that the SSD controller refrains from making the later write request durable until it is determined that the prior write request is durable.   
     
     
         13 . The method for facilitating recovery from a crash as claimed in  claim 8 , the SSD controller receiving a flush request from the host after receiving the write request, the method further comprising:
 refraining, by the SSD controller, from acknowledging the flush request until it is determined that the write request is completed.   
     
     
         14 . The method for facilitating recovery from a crash as claimed in  claim 8 , the SSD controller further receiving a prior write request and a later write request, the method further comprising:
 refraining, by the SSD controller, from keeping the later write request until it is determined that the prior write request is completed.   
     
     
         15 . The method for facilitating recovery from a crash as claimed in  claim 8 , the nonvolatile memory further including a plurality of blocks that include the pages, the method comprising:
 by the SSD controller for each of the at least one written page that is written with the data, assigning a logical page number (LPN) in the spare area of the written page;   establishing, by the SSD controller, a full checkpoint through storing an entirety of a logical-to-physical (L2P) mapping table in at least one of the blocks of the nonvolatile memory, the full checkpoint containing a correspondence relationship between the LPN and a physical page number (PPN) for each of the at least one written page; and   establishing, by the SSD controller, an incremental checkpoint through storing a revised portion of the L2P mapping table revised after a latest checkpoint, which is one of the full checkpoint and the incremental checkpoint that was established the last, was established,   wherein each of the full checkpoint and the incremental checkpoint contains a seal page that records a WID corresponding to a latest write request at the time the corresponding one of the full checkpoint and the incremental checkpoint was established, and a PPN corresponding to a next free page of the pages at the time the corresponding one of the full checkpoint and the incremental checkpoint was established.   
     
     
         16 . The method for facilitating recovery from a crash as claimed in  claim 15 , further comprising:
 reestablishing, by the SSD controller, the entirety of the L2P mapping table by retrieving the full checkpoint stored in the at least one of the blocks;   revising, by the SSD controller, the L2P mapping table thus established by incorporating the revised portion of the L2P mapping table contained in the incremental checkpoint into the L2P mapping table thus reestablished;   by the SSD controller for each of write requests received after establishment of the latest checkpoint, counting a number of appearances of a WID corresponding to the write request in subsequent pages written with the data of the write request based on the PPN recorded in the seal page of the latest checkpoint to result in a post-crash WID count that indicates a total number of appearances the WID in the subsequent pages;   by the SSD controller for each of the write requests received after establishment of the latest checkpoint, determining whether the write request is completed based on the post-crash WID count and the request size corresponding to the write request;   recovering, by the SSD controller, a group of the write requests received after establishment of the latest checkpoint by using a recovery determination procedure which is related to completeness of the write requests; and   updating, by the SSD controller, the L2P mapping table thus revised by incorporating changes of correspondence relationships between the LPNs and the PPNs of written pages related to the group of the write requests thus recovered.   
     
     
         17 . The method for facilitating recovery from a crash as claimed in  claim 16 , wherein the recovery determination procedure includes:
 arranging, by the SSD controller, the write requests received after establishment of the latest checkpoint in an order the write requests were received;   by the SSD controller for every consecutive two of the write requests, determining whether the consecutive two of the write requests are coalesced; and   determining, by the SSD controller, at least one cut, with each of the at least one cut being between the write requests of a consecutive pair, where there is no coalescing for either of the write requests in the consecutive pair, and the write requests before the cut are all completed and serve as the group of the write requests to be recovered.   
     
     
         18 . The method for facilitating recovery from a crash as claimed in  claim 17 , wherein the recovery determination procedure further includes:
 determining, by the SSD controller, an optimum cut from among the at least one cut, where a number of the write requests before the optimum cut is the greatest among the at least one cut, and the write requests before the optimum cut serve as the group of the write requests to be recovered.   
     
     
         19 . The method for facilitating recovery from a crash as claimed in  claim 15 , further comprising:
 refraining, by the SSD controller while performing garbage collection, from reclaiming one of the pages that is written after establishment of the latest checkpoint.   
     
     
         20 . The method for facilitating recovery from a crash as claimed in  claim 8 , the SSD further including a write cache, the method further comprising:
 performing, by the SSD controller, internal flush on the write cache before performing garbage collection.

Join the waitlist — get patent alerts

Track US2022129420A1 — get alerts on status changes and closely related new filings.

We store only your email — no account needed. See our privacy policy.