Export thread
-
DNS Benchmark v2 is Finished and Available! Guest:
That's right. It took an entire year, but the result far more accurate and feature laden than we originally planned. The world now has a universal, multi-protocol, super-accurate, DNS resolver performance-measuring tool. This major second version is not free. But the deal is, purchase it once for $9.95 and you own it — and it's entire future — without ever being asked to pay anything more. For an overview list of features and more, please see The DNS Benchmark page at GRC. If you decide to make it your own, thanks in advance. It's a piece of work I'm proud to offer for sale. And if you should have any questions, many of the people who have been using and testing it throughout the past year often hang out here.
/Steve. -
Be sure to checkout “Tips & Tricks” Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!
/Steve. -
BootAble – FreeDOS boot testing freeware
To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.
GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.
The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.
You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.
(You may permanently close this reminder with the 'X' in the upper right.)
Is there a point at which slow SpinRite performance means the drive is bad?
#2
ColbyBouma
ColbyBouma
#3
brado2049
brado2049
Attachments
#4
ColbyBouma
ColbyBouma
#5
peterblaise
peterblaise
#6
brado2049
brado2049
Attachments
#8
Tazz
Tazz
#10
P
PHolder
In theory you could get a brand new drive plug it in, and your system could get fried by a lightning strike 5 seconds after you wrote some important file to the drive for the first time. Statistically that probably almost never happens, but my point... if I even have one... is that a drive is worth exactly as much trust as you have in it retaining your important data for a lengthy enough time to meet your expectations. I gather that's not very helpful to you, but I think, it's all I got. If a drive is acting wonky, or unreliable, you're setting yourself up for hurt if you put too much trust in it.
P
PHolder
That's a statistics problem hiding in sheep's clothing
In theory you could get a brand new drive plug it in, and your system could get fried by a lightning strike 5 seconds after you wrote some important file to the drive for the first time. Statistically that probably almost never happens, but my point... if I even have one... is that a drive is worth exactly as much trust as you have in it retaining your important data for a lengthy enough time to meet your expectations. I gather that's not very helpful to you, but I think, it's all I got. If a drive is acting wonky, or unreliable, you're setting yourself up for hurt if you put too much trust in it.
#11
brado2049
brado2049
#12
D
DanR
If SpinRite gets stuck and unable to move on -- that is bad.
If there any U's or B's in the Graphics Display Screen - that is bad. If there are only some R's that could be OK as it indicates SR recovered the data.
If there are errors at the bottom of the Real Time Activities screen - that is bad! Good drives will have zero errors; bad drives lots of errors. And then there is the gray area in between . . .
If the Detailed Technical Log screen has a very small scroll bar over on the RH side, that is bad! It means there is a LOT of data (likely error data) in the DTL to scroll thru - bad.
If the S.M.A.R.T. data sccreen is blank - that is bad.
The drive you initially posted about is bad. It is beyond SpinRite's ability to "fix" it. SpinRite can do things that seem like magic. But SR does have its limits.
In regard to the drive in your OP, there are a couple of things you might try for info and experience - if you wish to spend the time.
1) Try restarting at 2%, or 5%, etc to get past the initial trouble spot and see what happens
2) Try a DynaStat 0 run. Command line: "spinrite level 2 dynastat 0" and see what happens.
Bottom line: The drive in your OP is toast. It cannot be fixed by SpinRite. It is not to be used ever again. But as a learning tool for playing around . . .
D
DanR
Unfortunately, there is no good/bad black/white yes/no answer. It comes down to a combination of judgement, common sense, and experience.
If SpinRite gets stuck and unable to move on -- that is bad.
If there any U's or B's in the Graphics Display Screen - that is bad. If there are only some R's that could be OK as it indicates SR recovered the data.
If there are errors at the bottom of the Real Time Activities screen - that is bad! Good drives will have zero errors; bad drives lots of errors. And then there is the gray area in between . . .
If the Detailed Technical Log screen has a very small scroll bar over on the RH side, that is bad! It means there is a LOT of data (likely error data) in the DTL to scroll thru - bad.
If the S.M.A.R.T. data sccreen is blank - that is bad.
The drive you initially posted about is bad. It is beyond SpinRite's ability to "fix" it. SpinRite can do things that seem like magic. But SR does have its limits.
In regard to the drive in your OP, there are a couple of things you might try for info and experience - if you wish to spend the time.
1) Try restarting at 2%, or 5%, etc to get past the initial trouble spot and see what happens
2) Try a DynaStat 0 run. Command line: "spinrite level 2 dynastat 0" and see what happens.
Bottom line: The drive in your OP is toast. It cannot be fixed by SpinRite. It is not to be used ever again. But as a learning tool for playing around . . .
#13
brado2049
brado2049
#14
Tazz
Tazz
#15
brado2049
brado2049
#16
brado2049
brado2049
Attachments
#18
brado2049
brado2049
#19
peterblaise
peterblaise
Sadly, Backblaze has no published standards by which they replace a
drive or call a drive 'failed', that is, if they replace a drive because of
S.M.A.R.T. or other reports, WITHOUT FAILURE, or if the drive
actually becomes unable to read ( and write ) data, and then and only
then it is replaced <-- not likely.
I presume Backblase replaces drives BEFORE actual failure, and may
never retest after that, and as such, they may never know if the drive
would have eventually failed, or not.
As such, Backblaze's recommendations are most appropriate for large,
multiple-installation, financially ROI-based return on investment
organizations looking for assurance that they are avoiding LIKELY
risks, but they may not be reporting individual REALIZED risks.
I'd love to test Backblaze's deprecated drives to see if some are
perfectly fine by my standards, or if they really, really, really are a
waste of time and energy because critical failure is imminent or has
already happened.
Who knows?
- - - - -
So for those of us out here working with onsies and twosies, not a
server room of thousands of drives, we gotta deal with maybe the
x% of the drives that prove reliable, versus the y% that have failed.
There's no way to correlate our drive to Backblaze's report.
So, what do we do?
I ardently and continuously WATCH the
... screen to see if any region or sector is slow to read or write:
Illustrated ( perhaps subtly? ) here:
And, of course, watch the events enumerated on that screen:
... and toggling over to the [ Detailed Technical Log ] screen, for
example:
And through those views, circumnavigate the drive's read and write
performance.
Plus, listen to the drive, watch it's temperature, and so on, to become
intimately familiar with 'normal' and acceptable behavior, so I know
what unacceptable behavior looks like, sounds like, and feels like.
And compare to other drives, other makers' drives, and other models.
Eventually, we become familiar with 'good' versus 'bad' regardless of
the success of write-read tests themselves - I have bad drives that
have no failures, they pass all tests, but some of these supposedly
'good' drives are so sloggy that I can't tolerate waiting for them
anymore.
SpinRite is not a pass / fail test for whether or not we will be happy
with a drive.
That's our responsibility to develop the skill to know the difference.
So test those drives, end-to-end, and mark 'em [ TEST ONLY ] for
crapppy ones, and press the winners into service.
Let us know what you do.
Thanks.
drive or call a drive 'failed', that is, if they replace a drive because of
S.M.A.R.T. or other reports, WITHOUT FAILURE, or if the drive
actually becomes unable to read ( and write ) data, and then and only
then it is replaced <-- not likely.
I presume Backblase replaces drives BEFORE actual failure, and may
never retest after that, and as such, they may never know if the drive
would have eventually failed, or not.
As such, Backblaze's recommendations are most appropriate for large,
multiple-installation, financially ROI-based return on investment
organizations looking for assurance that they are avoiding LIKELY
risks, but they may not be reporting individual REALIZED risks.
I'd love to test Backblaze's deprecated drives to see if some are
perfectly fine by my standards, or if they really, really, really are a
waste of time and energy because critical failure is imminent or has
already happened.
Who knows?
- - - - -
So for those of us out here working with onsies and twosies, not a
server room of thousands of drives, we gotta deal with maybe the
x% of the drives that prove reliable, versus the y% that have failed.
There's no way to correlate our drive to Backblaze's report.
So, what do we do?
I ardently and continuously WATCH the
SpinRite 6.1 [ Real-Time Activities ]
... screen to see if any region or sector is slow to read or write:
Illustrated ( perhaps subtly? ) here:
And, of course, watch the events enumerated on that screen:
command timeout: 0 command aborted: 0 comm/cable errs: 0 not recoverable: 0 minor troubles: 0 sect neverfound: 0 dynastat recovr: 0 defective sectr: 0 ... and toggling over to the [ Detailed Technical Log ] screen, for
example:
And through those views, circumnavigate the drive's read and write
performance.
Plus, listen to the drive, watch it's temperature, and so on, to become
intimately familiar with 'normal' and acceptable behavior, so I know
what unacceptable behavior looks like, sounds like, and feels like.
And compare to other drives, other makers' drives, and other models.
Eventually, we become familiar with 'good' versus 'bad' regardless of
the success of write-read tests themselves - I have bad drives that
have no failures, they pass all tests, but some of these supposedly
'good' drives are so sloggy that I can't tolerate waiting for them
anymore.
SpinRite is not a pass / fail test for whether or not we will be happy
with a drive.
That's our responsibility to develop the skill to know the difference.
So test those drives, end-to-end, and mark 'em [ TEST ONLY ] for
crapppy ones, and press the winners into service.
Let us know what you do.
Thanks.
#20
D
DanR
- SpinRite is clearly stuck
- The DTL screen shows a very small scroll bar on the right, indicating lots of data (errors?) in the log - NOT good
- The drive is a Seagate; hence some SMART errors are not unusual for a good drive
- However, the RTA screen shows NO errors at the bottom - Good!!!
I note the the RTA screen shows a sector size of 32768 which is the maximum, and quite possibly too aggressive for this no longer optimum and likely now sensitive drive. You might consider starting SpinRite with the XFER command line token with progressively smaller values for progressively gentler touches, to see if something might work. Another learning experience!
Examples:
spinrite xfer 16384
spinrite xfer 8192
spinrite xfer 4096
Etc.
The suggestions in my previous post, for skipping the bad spot or trying DynaStat 0, for learning and experience would apply here to this drive.
But try the XFER options first!
D
DanR
I would say the drive may be bad.
- SpinRite is clearly stuck
- The DTL screen shows a very small scroll bar on the right, indicating lots of data (errors?) in the log - NOT good
- The drive is a Seagate; hence some SMART errors are not unusual for a good drive
- However, the RTA screen shows NO errors at the bottom - Good!!!
I note the the RTA screen shows a sector size of 32768 which is the maximum, and quite possibly too aggressive for this no longer optimum and likely now sensitive drive. You might consider starting SpinRite with the XFER command line token with progressively smaller values for progressively gentler touches, to see if something might work. Another learning experience!
Examples:
spinrite xfer 16384
spinrite xfer 8192
spinrite xfer 4096
Etc.
The suggestions in my previous post, for skipping the bad spot or trying DynaStat 0, for learning and experience would apply here to this drive.
But try the XFER options first!
#24
brado2049
brado2049
#25
peterblaise
peterblaise
#26
brado2049
brado2049
#27
brado2049
brado2049
#28
Tazz
Tazz
#29
D
DanR
SpinRite is merely giving you the option of changing your mind if a different level is desired.
BTW: You could also try XFER 2048 or XFER 1024, for example. However, progress could be slower as SpinRite's "bites" now involve fewer bytes.
D
DanR
In this case, Level 3 has been selected (via the command line) and will show at the very top center of the Level Selection screen.
SpinRite is merely giving you the option of changing your mind if a different level is desired.
BTW: You could also try XFER 2048 or XFER 1024, for example. However, progress could be slower as SpinRite's "bites" now involve fewer bytes.
#30
brado2049
brado2049
#34
brado2049
This makes for an opportunity for a worthwhile clarification on what that 32k -> 4k change actually does. My understanding is this determines the size of the blocks SpinRite performs read-write I/O with, so larger blocks, faster drive processing, but will also report issues against that amount of drive space. However, if there are errors or slow I/O (I don’t know all the myriad reasons which can contribute) within the drive location a larger block addresses, switching to a smaller block size can help to isolate the problem to a smaller area of the drive, perhaps revealing that it is only a smaller area which is actually having problems.
So for example, let’s say I use 32k block size, and am returned errors. If I reprocess that 32k area of the disk using a 4k block size, that addresses that 32k block disk area in 8 different 4k blocks, and SpinRite may now be able to determine that, for example, the error exists only in 4k block 5, not the entire 32k block area. I would assume this would favorably change the final statistics on the drive as a whole, and ideally show the drive to have issues on a lesser area of the drive. What it also does is further isolate issues to smaller areas and more specific locations on the drive, making it possible to focus just on those areas for additional SpinRite runs if desired.
Have I got that right? (If not, please someone set me straight! ) Anyway, returning to the drive in question, on this second run using 4k blocks, there doesn’t seem to be any significant difference in processing speed (though I wasn’t directly comparing 32k vs 4k estimated times), they both were just extremely slow, so I’m just letting this current 4k run complete, if it can. But the lack of much in the way of errors has got me thinking about the proper conclusion — what happens if this thing finally completes, and there are no (or very few) errors, but the drive processing was agnonizingly slow (which if stopped right now, would be the case)? Is that drive good to put back into use? Or is it bad, and should be destroyed with the other dead drives? Part of the idea of what I’m asking is if there’s a scenario where the drive is otherwise fine and will perform fine during normal use, but there’s something about the nature of SpinRite operations which on some drives just manifests as extremely slow processing, but doesn’t necessarily mean drive dysfunction. So in other words, dog-slow SpinRite processing, but the drive is still good. Can anyone speak to this?
brado2049
My original run on all of my hard drives used 32k blocks. After that first pass, I had 7 good drives, 3 bad drives, and 3 “iffy” drives which either had moderate errors or were processing so slowly they were either bad or needed different parameters. So taking the guidance of another (@DanR) earlier in this thread, I switched to 4k blocks for a second run only on the 3 “iffy” drives.
This makes for an opportunity for a worthwhile clarification on what that 32k -> 4k change actually does. My understanding is this determines the size of the blocks SpinRite performs read-write I/O with, so larger blocks, faster drive processing, but will also report issues against that amount of drive space. However, if there are errors or slow I/O (I don’t know all the myriad reasons which can contribute) within the drive location a larger block addresses, switching to a smaller block size can help to isolate the problem to a smaller area of the drive, perhaps revealing that it is only a smaller area which is actually having problems.
So for example, let’s say I use 32k block size, and am returned errors. If I reprocess that 32k area of the disk using a 4k block size, that addresses that 32k block disk area in 8 different 4k blocks, and SpinRite may now be able to determine that, for example, the error exists only in 4k block 5, not the entire 32k block area. I would assume this would favorably change the final statistics on the drive as a whole, and ideally show the drive to have issues on a lesser area of the drive. What it also does is further isolate issues to smaller areas and more specific locations on the drive, making it possible to focus just on those areas for additional SpinRite runs if desired.
Have I got that right? (If not, please someone set me straight!
) Anyway, returning to the drive in question, on this second run using 4k blocks, there doesn’t seem to be any significant difference in processing speed (though I wasn’t directly comparing 32k vs 4k estimated times), they both were just extremely slow, so I’m just letting this current 4k run complete, if it can. But the lack of much in the way of errors has got me thinking about the proper conclusion — what happens if this thing finally completes, and there are no (or very few) errors, but the drive processing was agnonizingly slow (which if stopped right now, would be the case)? Is that drive good to put back into use? Or is it bad, and should be destroyed with the other dead drives? Part of the idea of what I’m asking is if there’s a scenario where the drive is otherwise fine and will perform fine during normal use, but there’s something about the nature of SpinRite operations which on some drives just manifests as extremely slow processing, but doesn’t necessarily mean drive dysfunction. So in other words, dog-slow SpinRite processing, but the drive is still good. Can anyone speak to this?
#37
brado2049
brado2049
#38
brado2049
brado2049
#40
brado2049
brado2049
#43
peterblaise
peterblaise
@Steve Gibson left the
SpinRite 6.1 in development up to Release 4 to automatically change
the
write of 32,768 blocks reveals bad sectors to be worked on, then the
appropriate, even the equivalent of
That being said, I have found useful flexibility using various
values, especially on SSDs.
- - - - -
Note also that SpinRite 6.1 WRITES to a drive during enumeration,
so even
WRITE test.
To completely prevent writing, use the
line option, such as:
XFER option for edge-cases, but changed SpinRite 6.1 in development up to Release 4 to automatically change
the
XFER value dependent on the situation, where if a read and write of 32,768 blocks reveals bad sectors to be worked on, then the
XFER value will automatically drop down to whatever is appropriate, even the equivalent of
XFER 1 .That being said, I have found useful flexibility using various
XFER values, especially on SSDs.
- - - - -
Note also that SpinRite 6.1 WRITES to a drive during enumeration,
so even
LEVEL 1 , which is a read-only task, happens AFTER a WRITE test.
To completely prevent writing, use the
SKIPVERIFY command line option, such as:
SPINRITE SKIPVERIFY LEVEL 1 
#45
peterblaise
When you have a chance, now run a
it's 'healed'.
- - - - -
The blocks on the Graphic Status Display 72 blocks across x 14 blocks
down represent 1,008 equally proportioned parts of the total sector
count, for an example:
In my example, the total sector count is 3,907,029,167.
Divide that across 1,008 blocks means each block represents whatever
is happening in approximately 3,876,020 sectors!
Yeah, 3 billion sectors, each block represents 3 million sectors.
Wow. SpinRite has a lot to manage!
So any code displayed on a block could be from any one or more of 3
million sectors here.
Your drive has 5 billion sectors, so each block shows 5 million sectors -
approximately 5,814,021 to be approximate - of which, 2,823 were a
mess, about 0.049% of the displayed block is actually [ U ], which is
only 0.00000048% of the drive's total sectors.
Though one would think that 0.00000048% is trivial, it brings
everything to a halt when it's bad, doesn't it?
SpinRite is a wonderful thing.
;-)
peterblaise
"... LEVEL 3 DYNASTAT 0 ... ~56 hours, one unrecoverable [ block ] ...
Real-Time Activities: 2,823 not recoverable, no other errors ..."
When you have a chance, now run a
LEVEL 5 DYNASTAT 0 , see if it's 'healed'.
- - - - -
The blocks on the Graphic Status Display 72 blocks across x 14 blocks
down represent 1,008 equally proportioned parts of the total sector
count, for an example:
In my example, the total sector count is 3,907,029,167.
Divide that across 1,008 blocks means each block represents whatever
is happening in approximately 3,876,020 sectors!
Yeah, 3 billion sectors, each block represents 3 million sectors.
Wow. SpinRite has a lot to manage!
So any code displayed on a block could be from any one or more of 3
million sectors here.
Your drive has 5 billion sectors, so each block shows 5 million sectors -
approximately 5,814,021 to be approximate - of which, 2,823 were a
mess, about 0.049% of the displayed block is actually [ U ], which is
only 0.00000048% of the drive's total sectors.
Though one would think that 0.00000048% is trivial, it brings
everything to a halt when it's bad, doesn't it?
SpinRite is a wonderful thing.
;-)