Another before/after SpinRite story

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

drwtsn32

Active member
Sep 19, 2020
43
14
Dell Latitude E7440 w/ 256GB Samsung PM851 SSD
Laptop was feeling sluggish.

ReadSpeed results:
131.3 / 173.8 / 542.9 / 542.7 / 142.6

Ran SpinRite on level 3, which took about 2 hours to complete.

New ReadSpeed results:
533.2 / 528.5 / 533.4 / 530.7 / 531.2
 
  • Like
Reactions: Dakar Dad
Performed a secure erase on the SSD, which (from what I understand of SSD-aware secure erase utilities) causes the drive to do a quick voltage spike that clears all cells and resets them to a blank state.

ReadSpeed now shows:
542.7 / 542.6 / 542.7 / 542.6 / 542.5

Seems to support the idea that a SpinRite level 3 can make some regions appear slower since the drive now thinks there's data in those cells. After a secure erase the drive knows the cells are empty and instead of actually reading them it just spews zeros as fast as possible on the SATA interface.
 
@Steve reported that you could also run a TRIM on the drive so that it becomes aware that certain regions are actually not in use. This would achieve the same goal and not wipe the drive contents.
 
@Lob - yep that makes sense. In this case I already imaged the contents to another drive, so I didn't care about erasing it. I wanted to do the readspeed before/after test though. :)
 
Ran SpinRite on level 3, which took about 2 hours to complete.

New ReadSpeed results:
533.2 / 528.5 / 533.4 / 530.7 / 531.2

Performed a secure erase on the SSD, which (from what I understand of SSD-aware secure erase utilities) causes the drive to do a quick voltage spike that clears all cells and resets them to a blank state.

ReadSpeed now shows:
542.7 / 542.6 / 542.7 / 542.6 / 542.5

Well, isn't that interesting! In second case SSD is aware cells contain no data and immediately returns zeros. In first case it is not, in fact since Spinrite wrote to each LBA sector as far as SSD is concerned all cells in addressable LBA contain data.

The 5xx.y is ms per what again if I may ask?
 
@Steve reported that you could also run a TRIM on the drive so that it becomes aware that certain regions are actually not in use. This would achieve the same goal and not wipe the drive contents.

Well, not entirely of course. OS can can look up not-in-use clusters, for example NTFS keeps track of those in the $Bitmap file. OS then converts cluster addresses to LBA and 'trims' those. If you have one partition occupying entire drive with 30% free space, only those 30% would be trimmed.

Those 30% would give improvement when trying to read from any of those, SSD 'knows' it's empty LBA sectors and doesn't even read those => dramatic improvement.

If we would immediately write large chunks of data we would see less improvement as those 30% aren't immediately erased, so when drive is actually asked to write data and overprovisioned memory runs out it needs to go actively erasing. If we however grant the drive some to actually perform maintenance and erase the trimmed 30% we should also see write improvement.

At least that's how understand this. Same goes for the secure erase, until the drive actually got to erasing memory, read speeds improves dramatically (drive 'knows' requested sectors are 'empty' and immediately returns zeros), write speed not so much as it now has to quickly go to actually erasing blocks.

Edit: Another thought .. After erase command I expect actual erasing to be quicker than erasing after TRIM as SSD has no reallocation to deal with. It can just start zapping blocks as where erase as a result of TRIM, which concerns specific LBA ranges it may need to reallocate pages containing data that happen to be in same block.
 
Last edited: