To understand how these tools can have such a large improvement in speed when dealing with drives with bad sectors, you need to first understand what the OS is doing that is slowing it down. And the simple answer is retries. The OS refuses to accept that there can be bad sectors, and performs a stupid amount of retry attempts. This is happening at the driver level, and also possibly at an additional intermediate level. Before I made HDDSuperClone, I experimented with ddrescue and even had a passthrough patch for it. In my testing with Linux I could easily calculate that the OS was performing 5 retries. In older Linux kernels, it was 15 retries, but there was a way to get it down to 5 (setting a flag to perform direct IO without buffering). I think 5 was at the driver level, and there was an additional multiplier of 3 retries at an intermediate OS level.
Looking at Larry’s numbers, it would appear the retries are between 4 and 8 (DFL-DE = 8, R-Studio = 4, and DMDE = 5.7). If I had to guess, the standard retries here is 4 with an intermediate multiplier of 2 (R-Studio may be using a direct flag as it does in Linux). I can’t explain the 5.7x of DMDE. Some of this could be retries done within the programs themselves.
So if the retries are not too much different than Linux, why is Windows so bad with some failing drives? The only answer that I have for that is that when the bad sectors contain important metadata (such as the MFT), Windows has a panic attack, and then a heart attack and stroke, and that intermediate multiplier goes up like high blood pressure, and the end effect is a locked up computer until you remove the offending device. I think some of it may be that the OS is trying to be fast and using multi-threading to perform multiple read operations at once, and when they all hang, you are all done. Linux on the other hand, does not seem to get this panic attack, and just gives up after the normal retries, allowing quicker access to the disk. It also helps to have auto mounting turned off so the OS doesn’t try to read as much, but even if it is turned on, Linux will usually not lock up like Windows will.
So why is HDDSuperClone better in Linux? It uses direct passthrough commands. For USB storage devices this is SCSI passthrough. If you examined raw USB communication data, you would see SCSI commands. This basically bypasses the normal driver retries completely, as it is directly (as possible) sending and receiving the actual commands to the device, so it is just a simple send the command and get the results from the command, and it is up to HDDSuperClone to determine the status of the command. So bad sectors are only tried once in this case, further attempts would be in done in future phases of the recovery if they were enabled.
So my theory on how the USB Stabilizer works is that when it encounters a bad sector, it logs it, and then when there is another request for that sector (a “retry”), instead of trying to read it again, it immediately returns with a failed read. And when you return that fast, even though it is still a read error, it is very much helping to prevent a system lockup. I see similar results with my Virtual Disk Driver in HDDSuperClone, which because it is using the system in a backwards way, is just a computer lockup waiting to happen. But when the failed reads are instant, it is much more stable. It can’t be compared directly to the USB Stabilizer, but there are similarities in the concept of operation that allow me to make that connection.
So after seeing the price (WOW!), and the results compared to the free version of HDDSuperClone, which runs on a free OS, why would someone buy it? Simple, because it works with Windows and all of the recovery software that is made for Windows. As Larry indicated in his review, he was able to perform firmware commands through the stabilizer with his Windows based software, something that would not be possible with HDDSuperClone (you know, because it runs on that “other” OS that almost no one writes tools for). And it would also allow for a file level recovery as opposed to having to clone the whole drive first. Get past the price tag, and I could definitely see it being very useful.
And all of this is even without talking about the ability to power cycle. And I am curious about these lines in the features:
Quote:
Customizable read timeout duration in milliseconds.
Read timeout enforced by software reset, hardware reset, controller reset, or drive repower.
Other than a power cycle, I am curious what other kind of effective resets can be done with USB. I know there is a command to reset the USB port, but does it also really cause a reset to be sent to the drive itself, particularly in the case of it basically being a SATA device with a USB board (not a flash drive)? Did the read timeout actually have an effect in Larry’s Test? Considering the results of the HDDSuperClone comparison test, I would say no, the read timeout did not have an effect (smoke and mirrors?). From the log Larry sent me, I can tell that the failed reads took between 3-4 seconds. If the 1000ms (1s) timeout on the Stabilizer was working, it should have won hands down, but it didn’t. And the time almost perfectly matched the fastest time of the Stabilizer, so I would basically consider that a tie, meaning they both had the same effect. So far I have only dabbled in USB communication. I can see possible future experiments bouncing around in my head, probably not any time soon though…
P.S.
The Virtual Disk Driver in the Pro version of HDDSuperClone can also allow for file level recovery, but even I have to admit it is a bit touchy, maybe a little clunky and complicated, and requires more steps to get the end result. And of course it uses the dreaded Linux, and you are limited to only a few recovery programs that will work with it. But master it, and get one of the very affordable relay boards (get more than one, really, they are cheap) to use with it (yes you do have to do a little wiring), and it is one hell of a price difference for what you can do