What's going on with this flash drive?

[JorgeA]

One way you can verify this is by exiting and restarting SpinRite without powering down the machine. If SpinRite is willing to run on that drive again, after having previously declared that it's in Device Fault, then I/we still have a problem with SpinRite falsely declaring a drive emergency. But if (as I expect and hope) when rerunning, SpinRite marks the drive RED from the start and when you try to select it you learn that, yes, it's still in Device Fault, then SpinRite is doing the right thing and that drive really is "toast."

Hi Steve,

Yup, I just tried exiting and restarting SR without powering down the machine, and that's exactly what the program did: the flash drive is now shown in red.

In addition, I noticed that the 120-second countdown that was ticking during device discovery in previous rounds, did not show up this time.

The hope was that some drive-maintenance program might somehow block out the bad sectors on the drive so that an operating system could work around them, but it looks like that was not to be. To give an example from another problem drive, on one computer I had a 2TB HDD with two bad blocks out of thousands, and it was distressing to see that seemingly minimal proportion somehow working out to what Hard Disk Sentinel rates as "critical' with just 11% health.

To help a non-expert understand the situation, could we usefully draw an (admittedly gruesome) analogy to having one's jugular vein severed? After all, it's just one thin cut in one spot on the entire body, and yet...

 

[Steve]

@JorgeA:

SpinRite 7+ will definitely be obtaining file system awareness. At that point, it would be possible to have SpinRite take regions that a drive stubbornly refuses to spare out, out of service by the file system, thus potentially making the drive safe to use. The original SpinRite, starting with v1.0, had that technology for FAT file systems. I removed it from 6.1 to make room for everything new, and because support for only the FAT file system no longer made sense or was very useful.

Many people feel that drives should be either perfect or discarded. I understand and respect that position, but I don't have sufficient information to take a position either way. Perhaps once we get closer to SpinRite's next generation will have more to go on.

 

[JorgeA]

People putting all this effort into saving a $10 USB flash drive I can not understand TBH since that thing will never be reliable.

It's not merely about saving a modestly priced flash drive, it's about curiosity as to whether it could be fixed and how. Actually saving it would be icing on the cake.

 

[JorgeA]

The original SpinRite, starting with v1.0, had that technology for FAT file systems. I removed it from 6.1 to make room for everything new, and because support for only the FAT file system no longer made sense or was very useful.

Ah, so THAT'S where I got the idea that maybe it could be fixed! I didn't know that this capability had fallen by the wayside.

So this leads to a new question. I'm sure I still have the first copy of SpinRite that I downloaded, way back when. If one were to reformat the flash drive as FAT (it's currently NTFS), might that earlier version of SpinRite do the trick? There is, however, the prospect of its not knowing what to do with such a large drive (128 GB).

 

[JorgeA]

It can not be fixed. At best it can be masked or hidden or whatever you want to call it. It can be masked at firmware level or as you now propose at file system level. None of those is a fix. It's not the price I am concerned with, it's the poor quality of such devices that's reflected in the price. Again, often this type of error is indicative for the state/quality of the entire NAND chip, it's like putting a thin layer of paint over corroding metal.

I understand what you're saying. I don't know what the reputation of Lexar flash drives might be, but my experience with them has been perfect, until now.

Going back to the 11% healthy HDD, can you tease out the S.M.A.R.T. data below? I'm hoping to learn something, as to me this kind of chart isn't exactly a model of clarity. To a non-expert's eyes, most of the indicators appear to point to the drive's being in good condition, and even the ones with a yellow triangle say "OK (Always passing)". So how do we get from this picture to 11% health?

Thanks in advance to you or anybody who can help to interpret this information.

 

[JorgeA]

If you have recovered the data from the drive this seems a perfect candidate for SpinRite.

Thanks very much for the information!

Yes, the data on that HDD was safely copied over to a new drive, so we're not putting anything at risk. I did try to run SpinRite on the HDD, but tbe program would scan only the first 137GB. How to get SR to scan the rest of the drive?

 

[Steve]

How to get SR to scan the rest of the drive?

Until we're able to get over to SpinRite 7, the BEST THING to do, whenever possible, will be to arrange to directly attach a drive to a SATA (or IDE) adapter. That will be faster, will avoid the BIOS, and will give SpinRite the most direct access to the drive.

But, until then, Paul Farrer has developed a BIOS patch that CAN be used to remove this "yellow'ness" from SpinRite. The patching system is a bit tricky to use, but it does work and it has been proven to be safe. I don't know whether Paul has posted anything here in the web forums since this work was done in GRC's NNTP newsgroups and our GitLab.

 

[JorgeA]

I got a chance to install that 2TB HDD inside a PC. Here is a pair of shots from SpinRite's report:

BTW, the SR 6.1 level 2 scan went much faster than in earlier incarnations of SpinRite (although I'm sure you all knew that already!).

 

[Steve]

I got a chance to install that 2TB HDD inside a PC. Here is a pair of shots from SpinRite's report:

VERY nice! And SR7 will be able to do the same through a USB connection, which will be a big bonus.

 

[DanR]

got a chance to install that 2TB HDD inside a PC. Here is a pair of shots from SpinRite's report:

You might consider a Level 2 run, using DynaStat 0, starting just before the first bad block and ending just after the second bad block. DynaStat 0 will try re-writing something to the U sectors, thus typically forcing re-allocation of a non-writable U sector where a normal DynaStat run does not do a write if data is not recoverable.

However, any [potentially recoverable] data in the two U sectors would be lost. If this is not a concern then perhaps consider the suggestion above.

However, this leaves many unanswerable questions: What's next for this drive? Will one or more U's pop in the same general area at some point? Or elsewhere? And when? And if the U sectors are write-able, are they readable? And if so, for how long? This would seem to be another drive of questionable trustworthiness, suitable only as a SpinRite test specimen..

 

[JorgeA]

You might consider a Level 2 run, using DynaStat 0, starting just before the first bad block and ending just after the second bad block. DynaStat 0 will try re-writing something to the U sectors, thus typically forcing re-allocation of a non-writable U sector where a normal DynaStat run does not do a write if data is not recoverable.

However, any [potentially recoverable] data in the two U sectors would be lost. If this is not a concern then perhaps consider the suggestion above.

However, this leaves many unanswerable questions: What's next for this drive? Will one or more U's pop in the same general area at some point? Or elsewhere? And when? And if the U sectors are write-able, are they readable? And if so, for how long? This would seem to be another drive of questionable trustworthiness, suitable only as a SpinRite test specimen..

I went back to rescan the drive, starting with the "U" sectors, but none were found this time. I didn't adjust the DynaStat setting, didn't see a way to do it. May have to break down and RTFM to find out. (OK, I just found the instructions in the SR FAQ section. Good to know.)

Thinking that maybe I had input the wrong block locations, I ran a new level 2 scan of the whole drive to pinpoint the problem areas -- and again, no unrecoverable sectors were identified. The "ECC recovered" item on the S.M.A.R.T. screen now shows all the squares in white, with the current/max values at 114/114 (previously, 96/114).

I will have Hard Disk Sentinel and other utilities check this 2TB HDD drive and see what they have to say about it.

As you said, we can't be sure that the problem is permanently fixed. But I'm impressed anyway!

 

[Steve]

As you said, we can't be sure that the problem is permanently fixed. But I'm impressed anyway

Thanks for sharing your exploration. And this is almost always people's experience with SpinRite, which is why it remains a viable utility even after 35 years. And there's a LOT more in store in the immediate future.

 

[JorgeA]

Update on that 2TB HDD:

After the SpinRite level 2 scan, Hard Disk Sentinel did not find any bad sectors, and it now assesses the drive's health at 22% (up from 11% before the SR scan). FWIW.

The HDD passed every available test in Seagate SeaTools for Windows.

Currently running an Error Scan in HD Tune 2.55.

 

[JorgeA]

I recommend Victoria for Windows to perform an error scan. Victoria will identify any "slow" sectors. HDDScan is another such tool. MHDD is a better tool, but it runs under DOS, and you may need to select IDE mode in BIOS.

I'd never heard of that program, but last night I downloaded it and let it run overnight. Below is a screenshot. What do you all think?

 

[JorgeA]

It looks like the drive is in excellent health. When a drive starts failing, you'll see lots of 1.0 and 3.0 second blocks. Yours has none.

Huh, how about that. This is the same drive that Hard Disk Sentinel had said was at 11% health and then at 22% after the SpinRite level 2 scan.

So I can think of three different explanations:

1. Victoria is wrong and the HDD is dying;
2. Hard Disk Sentinel is wrong and the HDD is fine;
3. SpinRite improved the HDD to the point where it either looks or actually is in good shape.

Any other possibilities?

 

[JorgeA]

You should start treat these tools for what they are, they can only report what they 'see'. And you take that information and decide if you're still happy using that drive.

I work in publishing and not in any tech-related field, so drive health is far from being an area of expertise for me. When different drive health/maintenance utilities give me assessments that appear to run against one another, I'm not really in a position to know which assessment is more reliable.

I came to this forum with one or two problem drives (a flash drive and a HDD), hoping to learn what the nature of their problems might be and whether these problems could be fixed, and if so, whether the fix was worth the effort. Most of that has been achieved. The flash drive decision now seems pretty clear-cut, not so much for the HDD although I have learned a lot even there.

That HDD had been slated for junking, or maybe recycling after suitable wiping. Although it doesn't seem prudent to ever rely on it again as primary storage, maybe it can still serve as tertiary storage (a "backup of a backup") where its ongoing health status can be monitored.

One thing that I'm delighted about is seeing how fast the new SpinRite is. Formerly, I'd hesitated to run SR on these large drives because my previous experience with them suggested that a level 2 scan would take days or weeks to finish: imagine my surprise when this one was done in under 5 hours! Although to be honest, I'm not sure if this is because modern drive interfaces are faster, or because SR itself is faster, or maybe both factors contribute to the speed improvement.

 

[DanR]

One thing that I'm delighted about is seeing how fast the new SpinRite is. Formerly, I'd hesitated to run SR on these large drives because my previous experience with them suggested that a level 2 scan would take days or weeks to finish: imagine my surprise when this one was done in under 5 hours! Although to be honest, I'm not sure if this is because modern drive interfaces are faster, or because SR itself is faster, or maybe both factors contribute to the speed improvement.

SpinRite 6.0 is constrained to do all that it does by working through the BIOS. Thus, SR 6.0 is limited to s-l-o-w BIOS I/O speed.

SpinRite 6.1, OTOH, uses native drivers for accessing internal drives (NO BIOS involved!). Hence SR 6.1 can take advantage of all of the speed that modern drive-and-controller combos can provide.

 

[Steve]

Adding to what Dan wrote, one of the biggest accelerators aside from side stepping the BIOS is that SpinRite is able to work with far larger data transfer buffers. All use of the BIOS is strictly limited to 127 sectors, maximum. SpinRite's levels 3 through 5 transfer 32,768 sectors at once (16 megabytes) which can make a huge difference. SpinRite and its new native drivers are quick enough that levels 1 and 2 use 1,024 sector transfers since we don't miss any "revs" by issuing smaller requests. But the BIOS is limited to much smaller transfers since they need to fit within a 64K real mode "segment".

 

[JorgeA]

@DanR and @Steve, thanks very much for the details. I now understand the improvements in SpinRite much, much better!

And thanks to everyone else who pitched in with their analysis and suggestions.

 

[PHolder]

Assumption for example being you're going to ask for some sectors on same track. It works well I suppose if everything 'aligns'.

Well I don't know that assumptions are good for predictions on "random reads", but if the SPINNING device has enough RAM to read the entire track of the disk into RAM, and using that RAM won't otherwise cause problems for the device (i.e. it's not RAM limited to the extent it needs to discard something more important) then it does at least seem logical to me for it to always read the entire track into RAM because it's already sitting there spinning under the heads.