![\"\"](\"https:\/\/phisonblog.com\/wp-content\/uploads\/2021\/04\/1020559_1_032621.jpg\")
<\/p>\n[et_pb_section fb_built=”1″ _builder_version=”4.9.1″ _module_preset=”default” custom_margin=”0px||||false|false” custom_padding=”0px||||false|false” global_colors_info=”{}”][et_pb_row _builder_version=”4.9.1″ _module_preset=”default” width=”100%” max_width=”100%” custom_margin=”||||false|false” custom_padding=”0px||||false|false” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.9.1″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.14.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n
<\/p>\n
Over the past decade, solid-state disks (SSDs) have gradually taken the place of hard drives in many devices. More and more consumers and clients choose SSDs as their storage solution for notebooks, personal computers, and enterprise applications. As such, the need for SSDs to be reliable and secure is becoming more critical. The last thing anyone wants is for a faulty or aging SSD to be responsible for the loss of anyone’s crucial data. It’s necessary to monitor the health of SSDs and analyze an SSDs status to reassure a user that an SSD is still reliable and inform users when the life of an SSD is coming to an end.<\/p>\n
The standard SSD lifetime and workload analysis tool is S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology.) This tool records drive status attributes, including erase count, bad block count, uncorrectable error count, CRC error count, SSD life remaining, and more. More advanced analysis tools, such as protocol analyzer, UART mode, and drive log, help for debugging and protocol trace analysis when an SSD encounters unexpected errors that are hard to resolve immediately. In some cases, using drive log to clarify issues is simpler and more efficient than using protocol analyzer and UART. It can save an engineer time by not going back and forth between two places, allowing the engineer to focus on drive log analysis to resolve any issue quickly. Therefore, it made sense to Phison to create a drive log as a helpful debug tool, enabling our customers to be more confident in Phison’s after-sales service.<\/p>\n
Drive log saves in the data buffer. Once the host issues a vendor-specific command, such as a FLUSH command or idle, the drive log flushes into NAND flash to the SSD.
Drive log is comprised of three parts:<\/p>\n
<\/p>\n
<\/p>\n
\u2022 Public area: Records general and public events.
\u2022 Private area: Records confidential events.
\u2022 Non-overwrite area: Records events that, once recorded, can’t be overwritten even when the public and private areas are full.<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/phisonblog.com\/wp-content\/uploads\/2021\/04\/Updated-1020559_2_032621-1.jpg\")
<\/p>\n
Record information for host, FTL, and Flash IP save in drive log. The information stores the data by unique key words:<\/p>\n
\u2022 error event
\u2022 reset event
\u2022 abort event
\u2022 system event<\/p>\n
<\/p>\n
The record information in FTL has a different variable to log for assert events and other error events. As for the record information of Flash IP, the program error, erase error, and read retry in fail CE, block, and page.<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/phisonblog.com\/wp-content\/uploads\/2021\/08\/Ensuring-Data-Correctness-With-Phisons-GuaranteedFlush\u2122.jpg\")
![\"\"](\"https:\/\/phisonblog.com\/wp-content\/uploads\/2021\/04\/1020559_3_032621.jpg\")
<\/p>\n![\"\"](\"https:\/\/phisonblog.com\/wp-content\/uploads\/2021\/08\/Some-Common-Benchmarking-Tools-Used-in-SSD-Production.jpg\")