SR's handling and behavior with Solid State Drives

[sparkbash]

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.

 

[Steve]

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.

 

[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?

 

[Steve]

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.

 

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