Balance option - Stablebit Scanner

[thepregnantgod]

Drashna, I have a 8TB drive about 75% full that is damaged according to Stablebit Scanner.  It has about 9,173,295 sectors that are unreadable.

 

If I have put the Stablebit Scanner Balancer add-in to the top, selected the options Move unduplicated and duplicated files out of damaged drives, shouldn't it automatically "remove" all data from the drive and put it on other drives?

 

I ask because when I select "Remove drive" it goes for about an hour then reports an error "device not accessible."  

 

The only thing that pains me about your amazing software is this situation - removing a drive.  Usually if a drive needs removed there's something wrong with it and getting the data off of it is painful.  I can add a letter to it then manually copy it over but inevitably it gets added back to the pool because Drivepool still thinks it is (since I couldnt' remove it via Drivepool due to whatever fault that causes it to be flaky.)

 

 

[Christopher (Drashna)]

9 million sectors is ... a lot.  

 

That's either a false positive, or ... a lost cause. 

 

Make sure that you're on a build newer than 2.5.2.3109. 

http://dl.covecube.com/ScannerWindows/beta/download/StableBit.Scanner_2.5.2.3126_BETA.exe

 

There is an issue with newer drives that causes them to misreport information that absolutely can cause false positives.  

 

 

That said, the "device not accessible" issue ... is not promising.   Because, yes, unreadable (damaged) sectors should cause StableBit DrivePool to evacuate the contents of the drive (immediately, as a "triggered" event). (in fact, you can find quite a few threads about this happening to "unsuspecting" users). 

 

The problem is ... this is likely exactly what is happening. But the increased disk load on this drive is amplifying the problem, and causing the drive to drop from the system.   This isn't unheard of, though. 

 

I would recommend doing one of three things though: 

1. Run a burst test on the drive in question (make sure it's not a communication issue, which can trigger this behavior too).
2. Reset the cables for the drive in question. 
3. Immediately disconnect the drive, and maybe see about testing it in another system. 

[thepregnantgod]

Can you tell me more about the false positive?  It's a brand new drive.  I ordered a replacement immediately from Amazon and just got it today and want to swap it out but if I don't need to.

[thepregnantgod]

So, here's what's confusing, I marked unreadable blocks -"unchecked" forcing them to retest the unreadable sectors

 

Now, it's down to 639,929 sectors vice the original 9million sectors.

 

I have the latest beta for the program.

And now...perfectly healthy?  (I retested the other sectors).

 

So what's the issue?

[Christopher (Drashna)]

Let me quote the change log: 

 

 

.3109

* Apply the corrected size / bytes per sector / sector counts to the sector map on each service start.

* When correcting the size of the drive, also correct the bytes per sector and the sector count, but only if we can 

  validate the last sector.

* When reading the disk signature from the disk using Direct I/O, use the real bytes per sector. Some drives (like the 

  WD My Passport) will show up, incorrectly, as having 4096 bytes per (virtual) sector.

* When correcting the total size of the drive, validate the last sector before applying the new size. While this works 

  for most drives, some drives (like the WD My Passport) will report an incorrect size.

* If a manual scan was started on some disk, then automatic scanning was toggled on, and the disk that was being scanned 

  manually was not scheduled to scan, then the manual scan could not be stopped afterwards. Also, the service would not 

  shut down properly in this state.

.3108

* [issue #14557] Added DirectIO_DoNotCorrectSize advanced setting. When set to True, we won't correct the drive size 

                 based on the data that we get back from the disk directly. The service will need to be restarted for 

                 this to take effect.

 

 

 

Basically, some disks return incorrect information about the drive's "geometry".  Meaning that we may be scanning for sectors that are "out of bounds" of the disk.  Since they don't exist, the disk comes back with an error... since it .. .well, doesn't exist. 

 

This bug was introduced a while ago, as ... well, a way to attempt to fix this exact sort of issue from occurring.   

 

From this issue, specifically (IIRC):

 

* [issue #13478] Use the sector count reported by IDENTIFY if the sector count reported by Windows is smaller.

 

 

Worse, is that the drives that do this actually may (do) shift the information around frequently, so one scan may go better than another, or you may see it scan where a huge section has errors, but further on, it doesn't. 

 

 

But with the beta, we do some more vigorous checking of the disk info, so that we don't "get this data wrong".   

 

 

 

 

So the release version may not have issues (but in rare cases, it will), but the public beta was much more likely to do so. 

[thepregnantgod]

Thanks, Drashna.  

[Christopher (Drashna)]

You're very welcome.