Any specifics about SpinRite and SMR 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.

Santiago

known trekkie
Sep 25, 2020
4
0
Hello all,

I've been googling to find any info about running SpinRite on level 3 or above on SMR drives for maintenance. Other than being slow, having to re-write everything twice, any reason why it would be harmful to the drive?
 
I do not know exactly how SMR drives work inside, but the media itself should probably be fine with being rewritten, it may even be a good idea to do that periodically for magnetic media. The only thing I worry about for SMR is that it does several levels of caching in there to maintain speed, and I wonder if that caching (the data of the drive) persists if there is a power outage while it is in that super slow mode, but if there is no such problem being encountered I think there won't be a big problem.

However I also imagine that SMR does have smaller margins for errors, since it does in fact overwrite part of the width of each track, meaning there is less magnetic media holding the data.

Random SMR related thought: I think maybe SMR drives would actually benefit from having a TRIM command like SSDs, as if the drive could be told by the OS "yeah I don't care about this data anymore" it could rearrange data while idle to allow faster writing.

Also I am sure if data on SMR drives had an index of sorts of where each cluster's actual location was, it would allow the drives to write faster, though data would get more fragmented in that case.
 
  • Like
Reactions: Santiago
The only thing I worry about for SMR is that it does several levels of caching in there to maintain speed, and I wonder if that caching (the data of the drive) persists if there is a power outage while it is in that super slow mode, but if there is no such problem being encountered I think there won't be a big problem.

I am worried about caching also, but not about power outages. I don't know if the CMR cache in DSMR drives allows SpinRite to see the real sectors in the drive.

When SpinRite sends the command to write to a sector, will the drive write to that physical location? or will the drive redirect it to the CMR cache and report that to SpinRite. If it's writing it all to the CMR cache this would essentially trash the drive.
 
Power outages have always been a concern for SpinRite. The only way to be totally safe would be to find an area on the drive — or perhaps on another drive — where the data being re-written could be stored. But the overhead of being 100% power failsafe is very heavy, requiring a "safety write" for everything being read. If the safe area is on the same drive, that means a huge amount of head travel back and forth to write the backup data. With a second drive that would not be so bad.

With v6.1, we're going to have a huge speed advantage, so the extra write would be less burdensome, but still significant.

So... Through SpinRite's 35 year life, we've never been power failsafe... and it's never been an issue... though the question certainly has arisen.
 
Power outages have always been a concern for SpinRite. The only way to be totally safe would be to fine an area on the drive — or perhaps on another drive — where the data being re-written could be stored. But the overhead of being 100% power failsafe is very heavy, requiring a "safety write" for everything being read. If the safe area is on the same drive, that means a huge amount of head travel back and forth to write the backup data. With a second drive that would not be so bad.

With v6.1, we're going to have a huge speed advantage, so the extra write would be less burdensome, but still significant.

So... Through SpinRite's 35 year life, we've never been power failsafe... and it's never been an issue... though the question certainly has arisen.
Do I smell a cross-promotion deal with APC??? 😉
 
  • Like
Reactions: Steve
I got an UPS to help me feel safer from power outages yeah lol. I also think I am going to recommission a shoe box sized computer that draws 40W (tops) for spinrite duty at some point when I have time to play with that :) leaving its front open for slotting in drives to be tested, it is able to handle two drives :)
 
  • Like
Reactions: Dave
Yes, a UPS is a *must* for a reliable computer. Not just when running SpinRite, but at any time the results of the computer really matter. You'd probably be surprised how noisy/faulty most utility supplied power is, and a UPS can help with that. There are online UPSes that are much more expensive, but even condition the power in such a way that your PC is basically always being fed by the UPS. After a quality power supply, the second thing I always recommend to new computer builders is a UPS.
 
  • Like
Reactions: sttngs1
@Steve, power aside, do we have any idea if SMR drives pose any additional challenges for SpinRite? Is it possible that SpinRite could identify a SMR drive (or the technology in general) when it first encounters a drive, or is that info unavailable from querying the drive?
 
The "Identify Drive" sector has been steadily evolving since the very first IDE drives. A distressing proportion of it is gradually becoming occupied with “Obsolete” sections since the maintainers of the ATA spec do not wish to confuse older software by repurposing no longer needed fields, and there was no foresight about versioning sections of the sector.

But I would not be surprised to learn that there is a specific flag bit (they're big on flag bits) that makes such a declaration. And we also have the idea of a spinning drive explicitly supporting the TRIM command — for which, not surprisingly — there is a flag bit.

Given the nature of modern drives and their hyper-pervasive read error correction, I'm wondering more and more whether dramatically increasing the read-side technology might be the way to go in favor of write inversion testing. I've learned a LOT from watching everyone's posted results over in grc.spinrite.dev... and I'm thinking that by very carefully watching a drive read — either a spinner or non-spinner — a future SpinRite might be able to selectively determine where selective surface testing might be useful.
 
  • Like
Reactions: Tazz
I still think there may be a use for rewriting the rust every so often, in case there is any fading going on, it is not a good idea for SSDs though I think, unless flash media also fades, does it (I don't think it does but I am not that knowledgeable).

Personally I am looking forward to more strongly persistent magnetic media, that requires a laser to change the direction of the magnetic field, HAMR and its cousins. They remind me of magneto optical disks.

Of course I still would love to see MRAM be used to replace flash and regular ram, to save on power and speed things up, but now I am drifting off this topic :)
 
One consideration with regards to SMR drives is that similar to SSD drives there's a translation table in between you and your data, that maps specific locations on the drive to LBA addresses.
 
Hi all. Might as well throw my 2 cents in. I posted the following about SMR drives on another thread. I didn't know they existed. A bit of googling says they have non trivial performance problems. I don't think I want any of those. Having said that, I only researched it for 10 minutes.


Re caching and power failure. I've turned off all write caching in the Windows control panel for just this reason. Of course, that won't affect SpinRite or ReadSpeed since Windows isn't running. A UPS will give you at most 5-15 minutes of run time on a desktop computer, unless the UPS is really huge. If you're looking closely, that might be enough time to get over to the PC and manually shut down SpinRite. After that, the UPS dies and poof goes your data. You also have to load test the UPS from time to time and replace batteries every few years.

Re flash fading. If I remember my long ago reading correctly, a flash drive that's reached it's write limit will only retain data for a year. The electrons leak out of the memory cell storage capacitors. So a highly used flash device can definitely fade. I think new devices can too but slower. For that reason I don't think I'd like SSD's for archival use without routine maintenance runs with SpinRite or something like it.

I think @Steve has talked about bit rot on spinning drives in the past. Somebody might have to start a thread on that. But, briefly, from what I remember, magnetic coatings can deteriorate over time, moving parts can freeze up, interface technology can become obsolete, file formats can become obsolete, and controller boards can fail. So, keeping anything for archival purposes more than a few years can be tricky. By the way, the organic dyes that get written on DIY CD's and DVD's can fail in a fairly short period of time. While I haven't followed this list closely lately, the ARSCList mailing list (Association for Recorded Sound Collections) talks about all kinds of deep in the weeds issues for saving data. https://www.arsc-audio.org/arsclist.html I'm sure there are many records management and archivists groups too.

May your bits be stable and your interfaces be fast. :cool: Ron
 
Re flash fading. If I remember my long ago reading correctly, a flash drive that's reached it's write limit will only retain data for a year. The electrons leak out of the memory cell storage capacitors. So a highly used flash device can definitely fade.

May your bits be stable and your interfaces be fast. :cool: Ron
It's somewhat comparable to a battery. Charge leaks away over time. And also, the more often a battery is charged (or flash programmed), the faster it leaks until eventually it's practically unusable. SSD firmware tries to counter the effect somewhat using various wear leveling strategies. It can juggle data around, refresh and all that. For that it needs idle time and power. So a SSD should not be disconnected from power for a long time.
 
Random SMR related thought: I think maybe SMR drives would actually benefit from having a TRIM command like SSDs, as if the drive could be told by the OS "yeah I don't care about this data anymore" it could rearrange data while idle to allow faster writing.
SMR drives do support TRIM. So that could help Spinrite guestimate it's dealing with SMR. Also SMR drives tend to have larger cache sizes.

Consequentially they handle deleted files similar to SSD drives, so deleted files are truly unrecoverable using end user file recovery software. Same for formatting, formatted > no recovery. Also with regard to failure, certain failure modes that can occur on SSD drives due to corrupted translation tables causing the controller to go stupid, occur on SMR drives too.
 
Last edited:
It's somewhat comparable to a battery. Charge leaks away over time. And also, the more often a battery is charged (or flash programmed), the faster it leaks until eventually it's practically unusable. SSD firmware tries to counter the effect somewhat using various wear leveling strategies. It can juggle data around, refresh and all that. For that it needs idle time and power. So a SSD should not be disconnected from power for a long time.
Instead of a battery, I'd compare it to a capacitor. Batteries use a chemical reaction to generate electricity, capacitors just store an electric charge, same as flash...and it will bleed away with leakage the same way.
 
Instead of a battery, I'd compare it to a capacitor. Batteries use a chemical reaction to generate electricity, capacitors just store an electric charge, same as flash...and it will bleed away with leakage the same way.
I use the battery analogy to explain the effect to people. 99% of the people recognize the effect when I use the battery analogy, I doubt if same number would apply if I used capacitor analogy.