SR's handling and behavior with Solid State Drives

  • 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.

sparkbash

New member
Jan 5, 2024
3
1
I've been looking through available documentation and searching for forum threads and I haven't quite found an answer to my questions about usage of SpinRite with SSDs so I thought it was fair time to post. I did watch Steve's 12 minute "What It Does" video on the website too. very useful, but doesn't mention nand storage.

I've been listening to Security Now for almost 2 years probably and I had never heard of SpinRite before (I'm Gen Z and was never quite personally afflicted with the need to use a hard disk drive maintenance tool -- I've been in IT and CS for only 6 years).

I'm aware of several major ways that SSDs work differently than HDDs. I know that they effectively take the same read/write instructions and then translate; I know most of them use a read/write cache and occassionally "flush"; I know that instead of working with individual sectors, these SSD firmwares usually store up writes in cache and then write an entire page to a new location instead of overwriting, and I know that when it does this it usually logically remaps the address in firmware so that the filesystem is unaffected; I know that some SSDs and even HDDs to hardware/firmware level encryption, distinct from FDE.

Sorry for all the preface.

So my question is -- does SpinRite 6.1 (or 6 for that matter -- Steve has been talking about 6.1 for longer than I've been listening) work around or bypass any of these features and quirks of SSDs? I don't have clarity of just how low of a level SR operates at. Is it able to work around / in spite of the write caching? I ask the same about Sector writes vs. Page writes -- is the read-write-read (or whatever combination for different SR operating levels) pattern SR performs basically lost on SSDs, undermined by the lack of direct overwriting on the chips?

I hope the heart and intent of my question is clear. I am trying to understand what Mr. Gibson has been able to make SpinRite 6.1 do in regards to SSDs, at a bit-level on-hardware... if I am so capable of comprehending the truth :)

To whoever chooses to read this, thank you for your time already.
 
The shortest answer to your question is “no, SpinRite does not treat SSDs any differently than HDDs.” (Nor, for that matter CMR versus SMR hard drives.) It treats them all as large linear fields of logically addressable sectors and it allows the drive's own internal technology to manage their mapping to physical media storage however they choose. SpinRite does what it can to be aware of the differing technologies for the sake of cautioning its users against unneeded writing to devices (SSDs and SMR spinning drives) that “prefer” reading over writing. But is also aware of (when the drive discloses) physical media sectors which are 4kbytes rather than logical 512 bytes. But, for example, it doesn't attempt to alter its behavior based upon internal paging organization.

SpinRite v6.1 is largely a “catch up” after 20 years of SpinRite 6.0. As such, I tend to push some planned improvements into the future for SpinRite 7... but with regards to most of the above, I doubt that will be changing much even under SR7 where I'll have more freedom and ability to do anything we want. All the feedback we're getting suggests that v6.1 is now (finally) delivering on its design goals.
 
  • Love
Reactions: sparkbash
thank you so much for the reply Steve 🙏 This does clarify my misconceptions, I think. And sheds light further on my ignorance.

My follow-on question (which I also mentioned in my twitter DM to you earlier), is given how SSDs work so much differently, why does SpinRite have such a beneficial effect on their performance? Is it by "accident", more or less, that causing the drive to read and rewrite a ton of data, even if in a completely different way than you ever intended for a spinning disc, does refresh a lot of the performance? SSDs are hard to think about because the logical "beginning" and "end" of the drive are effectively random.

Possibly a better way to ask my question, if it's coherent at all:
Given how SSDs and HDDs function so differently yet are handled the same by SpinRite which was designed for magnetic discs, what functionality of SpinRite A) works exactly as intended for SSDs due to their similarity to HDDs, B) does not have the intended effect on SSDs but still has a useful result nonetheless (by "accident"), and C) should absolutely be avoided on SSDs since it will cause harm due to their differences with HDDs?
 
Once upon a time, before the adoption of servo head positioning, SpinRite's non-destructive low-level reformatting of drives allowed the drive's tracks to be realigned with the mechanically drifting heads. That ended when heads were positioned by the servo data in the track itself. But even so, drives began relying more and more on error correction. Reading and rewriting the drive's data turned out to be good for drives. And this appears to be the case even for solid state drives which also depend heavily (and increasingly) on error correction.

In the case of SSDs, it's unclear (and doesn't appear to matter) whether data is rewritten "in place" or whether the drive's wear-leveling logic rewrites data to a different location on the physical media. Whichever the case, we have tons of demonstrated proof that when those written regions, which were originally extremely slow to read, are later read back following rewriting they generally read back far faster than originally. For SpinRite 6.1, this is sufficient. SR7 plans to go much further into examining read performance.
 
  • Like
Reactions: sparkbash
This makes great sense to me and is all the clearer. I admire how well-honed your ability is to distill decades of specialist knowledge with such brevity.
 
  • Like
Reactions: Steve
I'd argue that any data on whatever type of drive benefits from being re-written every now and then. If we limit ourselves to NAND flash based drives like SSDs there's known 'mechanisms' that introduce bit errors, such as NAND cells bleeding charge or NAND cells gaining charge due to nearby cells being programmed. The tinier the cells, the more this is a problem. The more bits per cell, the more this becomes a problem.

So periodic refresh is even more important for SSDs than it is for HDDs. In fact it's so important that you may assume a modern SSD will 'patrol' the 'surface' and regularly rewrites data during idle time. And in fact it's so important that modern SSDs keep not only track of what's written where but also when it was written so it can refresh the data in time. It may even take into account the number of times a page was programmed and erased already as this affects the ability to retain data.

If SR (or any other r/w surface scanner FTM) reads data successfully and writes it back to the drive, it does not matter whether it's written to same location or not (it's not almost by definition), fact is it is written to freshly programmed cells. A drive may have less trouble (need less time and effort) reading from freshly programmed cells than cells that were programmed some time ago and may need more error correction and recovery than the freshly programmed ones.

We have even seen examples of improved read speeds after merely read-only scanning the SSD using SpinRite. Modern SSDs are not dumb devices that just deliver data on read, and so if reading data requires more effort (error recovery and correction) than some preset threshold, a drive may even decide to reallocate the data by itself. In this respect SR has same function as it had on spinning drives where a drive itself can decide to reallocate a sector because it had enough or better, too much trouble recovering the data.

This 'smartness' is a 'blessing' because a SSD would not survive without it, but also a potential problem, as the more complex managing the SSD becomes and so the algorithms responsible for it, the more room for error, and certain conditions may for example simply cause the firmware to loop indefinitely causing the SSD to become unresponsive.
 
Last edited: