SpinRite v6.1 Now at Release #3

[eugenschmidt]

Dear Steve,

First of all, thanks for the awesome software! I finally am a SpinRite owner, and it did me good already.

However, I think I should tell you about some issues I've experienced with SpinRite 6.1 rel. 3 yesterday. My machine is based on an ASUS P8Z77-V LE Plus motherboard that has 7 SATA ports on it, 6 of them provided by Intel Z77 controller (2 x SATA 3, 4 x SATA 2), and one SATA 3 by a Marvel controller. Yesterday, as I first booted into SpinRite, I had my OCZ Vertex4 256 GB solid-state drive plugged into the Marvel port, and my 2 TB Western Digital WD20EARX spinner plugged into one of the Intel SATA 3 ports, a configuration that served me well for almost 10 years.

As SpinRite started detecting drives, it hanged after detecting the spinner, and, after waiting for about 15 minutes, I had to resort to a three-finger-salute. I tried again, and this time I watched the same screen (photo attached) for about 30 minutes; after that, even my keyboard went unresponsive (to a point of NumLock LED not lighting up), so i had to power-cycle the machine.

At this point I found that my system would no longer boot from the SSD. I had to plug it into the spare Intel SATA 3 port to even have it detected, and I had to re-install the UEFI bootloader to make my system bootable again. In this configuration, with both drives on the Intel controller, SpinRite correctly detects both drives and is able to work with them.

I'm still not sure whether my Marvel controller went completely FUBAR, or I can still make it usable somehow. I'm also not sure if it was SpinRite that caused the controller to die, or it was just a coincidence. However, since I have no spare P8Z77-V LE Plus motherboard to reproduce the issue, I thought I should make you aware of it just in case.

 

[Keith S.]

I keep getting a error 404 ( page not found ) when I click on the GRC's Pre-Release page. I tried various locations where this link is found which includes Steve's April post where he announced the release of the new version. What gives?

 

[Tazz]

I keep getting a error 404 ( page not found ) when I click on the GRC's Pre-Release page. I tried various locations where this link is found which includes Steve's April post where he announced the release of the new version. What gives?

That was moved to the Upgrade page.

 

[fnap22]

Running in any virtualization environment is unsupported and not particularly well tested. You’re the first person I’ve seen who’s even attempted running in VMWare. I wrote all the VirtualBox instructions and had good luck on all 4 of my machines under VirtualBox but if I hit a failure point I wouldn’t consider it a SpinRite problem unless it was seen in native mode.

Is your system able to boot FreeDOS natively?

I'm also running SR 6.1 on a VM (Hyper-V)... Getting past the memory test is not a problem, but I keep getting errors when it looking to identify the drive. I've used SR 6.0 on Hyper-V for years and didn't have any of these problems. BTW ... this Drive is connected via USB-C and is OFFLINE on Windows and added as a physical drive to the VM.

One of the errors is: "SpinRite is attempting to confirm this drive data transfer safety" it just sits on this red warning box for quite some time (~1hour) ... I've walked away for a while and sometimes if comes back, identifies both partitions on this 1TB drive but won't scan it. Is this normal behavior for SR 6.1?

 

[Scott]

One of the errors is: "SpinRite is attempting to confirm this drive data transfer safety" it just sits on this red warning box for quite some time (~1hour) ... I've walked away for a while and sometimes if comes back, identifies both partitions on this 1TB drive but won't scan it. Is this normal behavior for SR 6.1?

No it isn’t. SR 6.0 always used the BIOS to communicate with the drives, but 6.1 has native drivers to talk to AHCI and IDE controllers. Maybe those drivers don’t like Hyper-V.

Try starting SpinRite 6.1 with the forcebios command line switch.

 

[fnap22]

No it isn’t. SR 6.0 always used the BIOS to communicate with the drives, but 6.1 has native drivers to talk to AHCI and IDE controllers. Maybe those drivers don’t like Hyper-V.

Try starting SpinRite 6.1 with the forcebios command line switch.

Thanks for your quick response Scott. I did try it again with the forcebios switch and it's working fine now. It did warn me that I'll take a major performance hit as a result. At least it's working now and drives were identified in seconds. The problem is that it now shows that is estimating that it will take "94" hours to do a L3 scan on a 1TB drive. It would be nice if I could really see and take advantage of the performance enhancements in SR 6.1.

If I have time I will try this again on a spare physical computer to see how it behaves.

Thanks
-Fino

 

[SeanBZA]

Physical hardware always trumps virtual.

 

[AlanD]

BTW ... this Drive is connected via USB-C and is OFFLINE on Windows and added as a physical drive to the VM.

That's where the problem is. If the drive is USB connected, SR6.1 can only see it as a BIOS device, and it will be limited to BIOS type speeds. The speed advantages of 6.1 are only for AHCI or SATA drives.

 

[Scott]

That's where the problem is. If the drive is USB connected, SR6.1 can only see it as a BIOS device, and it will be limited to BIOS type speeds. The speed advantages of 6.1 are only for AHCI or SATA drives.

But… in VirtualBox (and I assume VMWare), you can map any type of drive that the host can see to an AHCI or IDE adapter, and SpinRite can use its native drivers to addressntye drive.

 

[Will Fastie]

SpinRite v6.1 has been moved to its third release. I don't yet have a "change tracking" page setup since that will be part of the forthcoming SRv6.1 online docs. But here's what's new/fixed/different:

1. Removed the "drive not reporting writes" reporting and added a notice about possible RAM reliability being the cause of any apparent verification failure.
2. Added startup RAM testing to verify transfer safety.
   • Added NORAMTEST command line option.
   • In auto mode, RAM the RAM test runs for 60 seconds then self-cancels unless problem found.
3. Fixed trouble with VIA chipsets
   • Improved detection of missing drives on VIA controllers.
   • Bus Mastering now works 100%
4. Changed interaction between “DYNASTAT 0” and “NoRewrite” so that NoRewrite takes precedence (as it clearly should.)

As always, until SpinRite is formally published (once I get docs online) you can grab it at: GRC's Pre-Release page.

@Steve ,

I'm now the editor of the AskWoody Newsletter. We are currently reviewing SpinRite v6.1 and we have some concerns about the results. I do not want to share this information publicly because of uncertainty about our evaluation methods, so a private channel is preferred. This relates to SSDs.

Will

We have not spoken or written in years, so this reminder: Will Fastie, ex of Creative Computing, PC Tech Journal, Zif-Davis, etc. You have my contact info in your customer database or check fastie.com/about. I'll provide information about our reviewer.

 

[ColbyBouma]

You have my contact info in your customer database or check fastie.com/about. I'll provide information about our reviewer.

I recommend reaching out to him through email. He may not see your message here.

https://www.grc.com/mail.htm

 

[DanR]

We are currently reviewing SpinRite v6.1 and we have some concerns about the results.

FYI: SpinRite 6.1 is currently at Release 4 (the final release) which fixes issues in Release 3.

 

[Steve]

Thanks guys!

My guess is that their reviewer's testing of SpinRite with an SSD fully "untrimmed" the drive, resulting in apparently much slower post-SpinRite operation & benchmarking. As we know, this will be an issue until the drive is returned to an OS where it's file system can be used to retrim the drive. (And it will also be an issue until we get to SpinRite 7. )

I've reached out to Will so I'm on it!

 

[SeanBZA]

That won't affect read-only benchmarking.

That actually will affect it, as the read will tell the drive that this LBA unit is in active use, and thus is not part of an impending TRIM operation, as the data has been read. The drive merely keeps a list of LBA units that it has been told are not in use, as a way to have blocks it can simply erase and reuse, while not needing to first read the block, erase the whole erase unit whatever it is, then write the modified block back to that area. The reads set that this block, with the drive itself not caring about any filesystem structure higher up, has potentially valid data, so it will have to wait for a TRIM aware filesystem to mount the drive, and do a periodic scan of the entire directory structure, and see the blocks that have been marked as deletable, and tell the drive to TRIM them, which will mean the drive will use that space for storage by erasing the block on disk, then store the new data, without attempting to keep the data anywhere in that block. this will be in an internal table, which is invisible to the OS itself to a great part.

 

[DanR]

Typically the Spinrite before and after benchmarks are done on un-trimmed drive, and typically they show improvement.

Yes!

Note: Before SpinRite the drive's firmware knows that unused areas are empty and returns all zeroes on a read without actually reading them. After SpinRite the drive's firmware now knows that "something" has been written there and thus actually reads and returns all zeros for empty space. Hence an apparent decrease in performance for these areas. Until the drive is subsequently re-trimmed.

But used areas will typically show performance improvement with SpinRite.