Reporting Spinrite errors

[glarbstintonford]

Howdy. Long time listener, first time complainer. Not sure where to report or what to include, but better to get started than flounder around looking stuff up and inevitably getting distracted! There's a very good chance I'm flying in the face of better judgment vis a vis (heh) my setup, but... I really don't know.

I have SpinRite 6 running in a Vbox DOS VM, with an attached raw disk image of my probably 10 year old Seagate MyBackupSomethingOrOther 3TB HDD. I have tested a handful of other drives using this method with no errors. I backed up my files, formatted the disk ext4, then partitioned into 4 parts (500GB, 500GB, 1TB, 1TB) for Level 4 testing. The first three partitions passed, but the fourth partition is throwing these errors. The odd thing is that, of the three times I ran #4, the first and third times have very similar values. But none of the three times failed around the same timestamp--or it didn't seem that way. Hard to say, really.

Anywho, it's an old drive and even Seagate's Win10 utility didn't like her, but I figured I'd share.

If I'm leaving anything out (or wasting time), let me know.

 

[PHXdNelson]

AlanD had a great comment on this topic. Not the answer you are hoping to see, but I am guess the issue you are seeing:

https://forums.grc.com/threads/spinrite-hangs-at-discovering-mass-storage-devices.280/post-2329

 

[PHolder]

SpinRite 6.0 cannot handle numbers higher than 65k (65535)--this is the limit of a 16 bit number that is used internally. This means it cannot succeed on a drive with more than 2TB or so, so this is why it can't handle your 3TB drive.

 

[DanR]

I have tested a handful of other drives using this method with no errors. I backed up my files, formatted the disk ext4, then partitioned into 4 parts (500GB, 500GB, 1TB, 1TB) for Level 4 testing. The first three partitions passed, but the fourth partition is throwing these errors.

With the way this 3 TB drive is partitioned, SR 6.0 should not have any issue processing each of the partitions, as all 4 are well under SR 6.0's size limit of 2.2 TB.

The overflow errors in the 4th partition is most likely a Bios caused failure. This sometimes happens with SR 6.0.

The Bad news? There is nothing to be done with SR 6.0.

The Good news? SpinRite 6.1 will *not* have this issue!

 

[glarbstintonford]

That's all helpful, thanks folks. I do remember the 2TB limit now that y'all mention it.

Not sure what this says about anything, but I had the .vmdks mounted(?) as AHCI in vbox. Given that vbox lets me drag and drop drives between IDE and AHCI, my guess is it's in name only.

 

[Mervyn Haynes]

with an attached raw disk image

Surely this is missing the point of Spinrite is it not. If it is working in a VM and on an image of a drive, not the actual drive, what good could it do?
Now I may be way off the mark here, and would appreciate anyone correcting me, or an expiation of using this method.

 

[glarbstintonford]

Surely this is missing the point of Spinrite is it not. If it is working in a VM and on an image of a drive, not the actual drive, what good could it do?
Now I may be way off the mark here, and would appreciate anyone correcting me, or an expiation of using this method.

I honestly have no idea! What's the difference? A bit is a bit, no?

 

[AlanD]

Some people have found that if you mount the disk as RAW in a VM, SR6.0 will work on it. Normally, you cannot run SR under Windows or any other multi-tasing OS as it must have exclusive access to the disk. Mounting the disk in a VM and only in the VM gets round this.

Going back to the original point, although the partition may be less than 2TB, it's LBA addresses will exceed the 2TB barrier as they are counted from the start of the disk, not the partition. If you looked at the Partition table, it would have something like

Partition Start end
1 0 10000
2 10001 30000
3 30001 50000
4 50001 75000

The last value will be more than 64K

 

[glarbstintonford]

Some people have found that if you mount the disk as RAW in a VM, SR6.0 will work on it. Normally, you cannot run SR under Windows or any other multi-tasing OS as it must have exclusive access to the disk. Mounting the disk in a VM and only in the VM gets round this.

Yeah, RAW mount was the only way I could get it to work. To Mervyn's point, is it working the way is should? If the .vmdk is receiving an exact bit-to-bit copy from the platter, it should be the same, yeah?

Going back to the original point, although the partition may be less than 2TB, it's LBA addresses will exceed the 2TB barrier as they are counted from the start of the disk, not the partition. If you looked at the Partition table, it would have something like

Partition Start end
1 0 10000
2 10001 30000
3 30001 50000
4 50001 75000

The last value will be more than 64K

Ah, LBA. Of course. Can't get around that. Thanks.

 

[Mervyn Haynes]

If the .vmdk is receiving an exact bit-to-bit copy from the platter, it should be the same, yeah?

It might be the same at the time of reading, but the whole point of Spinrite is to work on the drive, not a copy of the data. It is not the same think. Just suppose you had a failing drive, and you managed to pull a copy of it just before it failed. That copy would pass the test, but not the original drive. Spinrite is meant to work on the original drive so it can fix problems. If you have a problem with the copy data, that region of the disk is not the same area as the original.

 

[PHolder]

If the .vmdk is receiving an exact bit-to-bit copy from the platter, it should be the same, yeah?

Depends on what the driver in the hypervisor is up to. If it just passes through the IDE commands without simulating the hardware and rebuilding them, then sure, it COULD work. On the other hand, there seems a high probability it might just be faking you out with virtual hardware and wonky drivers that only implement the minimal IDE commands.