I think this is the correct forum for this.

I've successfully run "sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror" any number of times, but today it ran for waaay too many hours without completing. (Early 2009 White MacBook/OS X 10.5.7 (Build 9J61))

(Note: Artie-s-Computer-4:~ artie$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *232.9 Gi disk0
1: EFI 200.0 Mi disk0s1
2: Apple_HFS HD 24.9 Gi disk0s2
3: Apple_HFS HD2 207.5 Gi disk0s3
Artie-s-Computer-4:~ artie$)

I tried substituting "disk0" for "rdisk0," but with no effect.

Has anybody got a clue what went wrong?

Thanks.

Sorry artie, i never did do much dd on an actual device. [i did play with it though... it can process anything you feed it.]

If i had to guess, i would say maybe the missing bs (block size) parameter might account for the long duration. Usually though, dd is fairly loquacious... you got no messages from it at all? Did you stop it via ctrl-C or how?

Anyway, i'll just toss in a few links here, to avoid readers having to search out where you got that from:

• Weird start up problem

• How to check a hard disk for I/O errors

Virtual1 is the voice you probably need to hear from.

I usually use 1024000 or larger as a block size. (that's about 1mb) You should select a bs that's an increment of the device's block size. (usually 512 bytes) 512 is the default, and if you try to do a lot of io with that block size, yes it will take ages.

I've also found that dd'ing the rdisk (the character device) is a lot faster than the disk (block device) but I don't understand why that is. I'd expect the block device to be faster.

Also IO speeds vary depending on the bus, and also on the architecture. PPCs for example are a lot slower on USB drives, even on the newest g5's with 480 USB. I've found also that firewire 800 is faster on intel than ppc as well.

I wouldn't use that noerr conv if you are looking for io errors. Maybe it's getting errors and that slows it down or locks it, and you're not seeing it because of this?

You can also use the count param to tell it how many blocks (of the size you've specified) it does.

If we don't use conv=noerror, the most "errors" we can ever find is one.

If we do use conv=noerror, it reports them (with exquisite detail) in realtime, and proceeds:


As to whether a single error should mean erase, remap and pray — or, just throw the disk away... it's hard to say. But I would tend to think that scanning a little further or a little deeper is harmless, and potentially more informative (than stopping immediately).

WOW. I just did a little testing with my new 800 drive and was astounded to find how SLOW it was running on the mac pro here. (original 8 core):

Service-Right:~ root # dd if=/dev/rdisk1 of=/dev/null bs=1024000 count=1000
1000+0 records in
1000+0 records out
1024000000 bytes transferred in 24.799520 secs (41291122 bytes/sec)

40mb/sec! This is with a firewire 800 cable going from the enclosure to the 800 port on the front. Wait... that's about fw400 speeds isn't it? Changed to a 400/400 cable from the 400 port on front with 400/800 adapter at the enclosure:

Service-Right:~ root # dd if=/dev/rdisk1 of=/dev/null bs=1024000 count=1000
1000+0 records in
1000+0 records out
1024000000 bytes transferred in 25.020858 secs (40925855 bytes/sec)

SAME. OK. Try rear 800 port instead of front:

Service-Right:~ root # dd if=/dev/rdisk1 of=/dev/null bs=1024000 count=1000
1000+0 records in
1000+0 records out
1024000000 bytes transferred in 11.909888 secs (85978978 bytes/sec)

Shazam! the 800 port on the front of the earlier mac pros runs at 400 speed!

I've already ran into a similar issue with my MBP, one of its USB ports runs a little slower than the other. (speed loss is almost identical to what you'd expect going through a USB hub so I am assuming internally that's the issue) But was NOT expecting this of the fw800 port on the front of the MP... The 800 port itself must just be wired up for 400, or the front panel board only has a 400 link to the logic board?

Additional:

I dropped block size from 1mb to 100k and upped block count from 1,000 to 10,000 (so still 1gb of data to test) and it cut transfer speed by about 15%. Going the other way didn't make a difference. So a block size of 1024000 (1mb) appears to be optimal for high speed devices. I also tested just now on a newer mac pro with dual 800's on the front and they do run at 800 speeds.

One more thing it occurred to me to check is system profiler, to see if it lists as a 400 or 800 device:

So it looks like Apple's hiding the issue ... Or rather they only tell you what everything is theoretically capable of, and don't tell you what speeds you're actually getting in the current configuration. Smacks of Vista Home telling you that you have "4gb RAM installed" and then with enough digging it admits "3gb usable".

Wow again. The revelations continue. This is the first time I've had my hands on a quality enclosure and it has USB (and eSata) on it as well so I'll test the USB also.

front USB: 1024000000 bytes transferred in 26.672113 secs (38392159 bytes/sec)

38mb/sec on USB. I have never seen that good before. This is on the front USB port but I expect the back to be the same.

Next is my mbp (2.5ghz).

left USB: 1024000000 bytes transferred in 60.710148 secs (16867032 bytes/sec)
right USB: 1024000000 bytes transferred in 30.782929 secs (33265191 bytes/sec)

Yes really. Right port is twice as fast as left port. Internally, the magport, usb port, and audio ports are on the "left io board", a separate part from the logic board, and I assume this is why it's slower, but that's sure quite a difference!

If memory serves me correct, I was getting a typical 9-12mb/sec on all the previous USB-only externals I've tested. (western digital, maxtor, hitachi) They must have low quality bridge chips - I don't think a really slow HD can even produce speeds that bad.

PMG5 here (dual 2)

front USB: 1024000000 bytes transferred in 64.991735 secs (15755850 bytes/sec)
rear USB: 1024000000 bytes transferred in 63.125977 secs (16221531 bytes/sec)
FW400: 1024000000 bytes transferred in 24.173656 secs (42360163 bytes/sec)
FW800: 1024000000 bytes transferred in 12.885357 secs (79470052 bytes/sec)

So on the G5 there's little usb port difference, and the FW is about the same as on the MP, though it's usb speeds are definitely a lot worse overall. (more than twice as slow) But nice to see the intels getting closer to the potential max for USB.

Lessons learned for greater disk speeds:

1) avoid all cheap large USB-only drives
2) avoid USB connections on PPCs
3) use FW800 whenever possible, it's worth almost any additional bother/cost

Just the last test on the PPC showed a difference in copying a gig, between 13 and 65 seconds, depending on connection. That's just HUGE.

FWIW, I installed what looked like a good quality USB card in my G5 at home, and it did nothing to improve speeds, so I assume it's an OS issue. (bus issue would affect firewire too wouldn't it?)

Replying to both Hal and V1...

I finally just bit the bullet and let "dd" run despite both the "apparent" time issue and the high temp at which my deuced Mac(hina) was running, and when it finally completed I realized that I must have originally run a "bs" much higher than 512, hence the time and temperature differences I was experiencing.

> Did you stop it via ctrl-C or how?

Hmmm... I knew there was a keyboard command, but I couldn't remember it, so I ran sudo kill (dd process #).

Since you posted, though, I tried control-C, but all it did was de-focus my Terminal window; control-option-C, on the other hand, did kill the process, but with this anomalous entry:

Last login: Mon Jan 11 03:05:06 on ttys001
Artie-s-Computer-4:~ artie$ sudo dd if=/dev/rdisk0s2 of=/dev/null conv=noerror
^C33373+0 records in
33373+0 records out
17086976 bytes transferred in 6.338757 secs (2695635 bytes/sec)
(Emphasis added)

(Note: I ran TechTool Deluxe>Surface Scan when I experienced the "anomalous" Terminal behavior, and it didn't return any errors.)

Thanks to you both for your thoughts.

control-option-C
There is no such animal (by default).
Maybe your keyboard is on the blink too.

I don't know what made your Terminal window lose the focus on your first attempt, but I'd bet that Control-C stopped the dd process the second time, and the Option key was extraneous. I ran the command you referenced in your initial post and stopped it by typing Control-C; this is my Terminal transcript:

$ sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror
Password:
^C3359+0 records in
3359+0 records out
1719808 bytes transferred in 3.897634 secs (441244 bytes/sec)

Other than a different set of numbers, adding Option to the key combo yielded the same result.

That caret/capital sequence is the symbolic representation of the Control-C key combo, which always shows up in Terminal's output when you use it to stop a process.

I dunno...

As both you and Hal have posted, and quoting Terminal Help>Shortcuts for Terminal:

(Strange wording?)

But the only way I've gotten to a "^C" dialog is with control-option-C or control-shift-C (entered in the same shell within which "dd" is running).

Control-C causes my Terminal window to lose focus, and even after reselecting the window and repeating the command "dd" is still running.

I have to assume that I'm doing something wrong, but damned if I can figure out what it is.

(It shouldn't have any bearing on the issue, but for what it's worth, I did an erase and install less than a week ago.)

Hey artie, sound like a hardware thing... but maybe not.

Show us what this command produces...

stty -e

--

Also, let's look at ctrl-C for some command other than dd.
Start measuring your home folder...
du -s ~
After one or two seconds, cancel it with ctrl-C
Assuming it works (i.e., du bails out), then do
echo $?
If it doesn't work, then do your ctrl-option-C,
and echo that status so we can see the value:
echo $?
[the value should be 130 btw]

Thanks for trying to unravel this...

Unfortunately, "du" doesn't run long enough for me to have enough time to enter ^C, so I did this:

Same results... It took ^-⌥-C to get to that ^C.

Does that first command's output tell you anything?

Oops...forgot the echo $? part:

What does that-all mean?

Mystery solved... I had usurped ^C to launch Calq.

I changed ^C to ⌥C, and Terminal now functions as expected.

Thanks for getting me thinking.

> Did you stop it via ctrl-C or how?

Hmmm... I knew there was a keyboard command, but I couldn't remember it, so I ran sudo kill (dd process #).


FYI, if DD is in the middle of a block (per its BS), particularly if it's lagging on an IO error or slow disc block (512), it won't respond immediately to ctrl-c. It may not even be easily killable in activity monitor. DD operations are kernel level and CAN block. DD will only respond to ctrl-c (as buffered) when it completes one of its blocks. (BS)

I finally just bit the bullet and let "dd" run despite both the "apparent" time issue

You should try my disk verify script posted earlier, it will give periodic progress reports. I have a more advanced version available, I'm always tweaking things like that, let me know if you want.

Okay... now let me try to have you rethink your keyboard shortcuts then: do not choose simple (single modifier) combinations.

1. By using ^C before, you blocked a vital Terminal function (and "readline" offers many ctrl-char combos... ctrl-R being one of my favorites).
   
   
2. By using ⌥C now, you probably can't type a cedilla on a lowercase c: façade

And don't think that readline/emacs shortcuts are limited to Terminal. Any Cocoa app (such as TextEdit) honors them. E.g., ctrl-A to move cursor to the beginning of a paragraph, ctrl-E to move to the end of a paragraph. I did it just now, while typing this reply in Safari. [to learn more than anybody ever wanted to know about that stuff, see: "Customize the Cocoa text binding system" -- edit: here is the <default list> also linked to in that article.]

So... for creating keyboard shortcuts to launch apps, etc., use ctrl-shift (or ctrl-command, or command-shift, or ctrl-option, or ctrl-option-command, etc) for your modifiers.


Must be a really tiny home folder, or a really (really!) fast Mac... or both.
Here's my (slow) PowerBook G4...

...and that's the 2nd run. First run took 18 seconds! (lots o' files)



If the exit code is 130 it means the process terminated due to receiving an INT signal, which is what ctrl-C sends. (i.e., a specific interprocess communication signal called "interrupt" and numbered 2. The 130 comes about by adding 128 + 2. It all has to do with the Bash shell, and which exit code values are allowed and what the reserved ones indicate).

A bit more science...

I threw three different surface scans at a 25Gb partition on my Early 2009 White MacBook/2.0GHz Core 2 Duo/1.07 GHz Bus Speed:

1. TechTool Deluxe
   (Sample per Terminal>top) Surface Scan > %CPU=9.5% > Time=0:01.66
   c. 470 sec
   
   
2. sudo dd if=/dev/rdisk0s2 of=/dev/null conv=noerror bs=10240000
   (Sample...) dd > 0.9% > 0:00.42
   26730483712 bytes transferred in 438.868714 secs (60907699 bytes/sec)
   
   
3. sudo dd if=/dev/rdisk0s2 of=/dev/null conv=noerror
   (Sample...) dd > 25.4% > 0:12.57
   3820858880 bytes transferred in 1473.733713 secs (2592639 bytes/sec)

I note that example 3, which was not run to completion, extrapolates to 10,310.14488 secs (171.835776 minutes) for the full 25Gb, close to a staggering 29 hours for my entire 250Gb HD, and that my HD temperature was the highest I've ever seen it while it was running.

I dunno... It seems to me that 29 hours is an extraordinarily long time and, too, that running for that long a period of time at a relatively very high temperature is likely to be detrimental to an HD.

Anybody?

And can anybody explain why TechTool Deluxe's "surface scan" is so much faster than "dd?"

> You should try my disk verify script posted earlier, it will give periodic progress reports.

Please excuse my ignorance, but which script?

> I have a more advanced version available, I'm always tweaking things like that, let me know if you want.

By all means; please post a d/l link.

Thanks.

Huh? Wait... wasn't #2 (dd) faster than #1?
If so, perhaps the question could be rephrased.

> Okay... now let me try to have you rethink your keyboard shortcuts then: do not choose simple (single modifier) combinations.

[....]

So... for creating keyboard shortcuts to launch apps, etc., use ctrl-shift (or ctrl-command, or command-shift, or ctrl-option, or ctrl-option-command, etc) for your modifiers.

(Thanks for the links.)

You're right on the mark, and your points are well taken, but...

When I was setting up my Butler configuration I got a whole bunch of pop-ups warning me that I might be stepping on something or other's toes, but, wanting to keep everything as simple as I could, I elected to face the consequences as they arose, and in the more than seven years since I made the decision only two commands have turned around and bitten me, i.e. command-], the loss of which is of no consequence to me, and ^-C, the loss of which, as I've noted, can be overcome with ^-option-C. (As a mater of fact, I've reset Calq's trigger to ^-C.)

Bottom line is I simply don't have enough need for the functionality presented in your linked doc (which, although it's an eye-opener for me, is not likely to change my computing habits very much, if at all) to start changing my triggers.

> Must be a really tiny home folder, or a really (really!) fast Mac... or both.


Most of what would normally be in one's home folder is located in a separate partition on my deuced Mac(hina).

Thanks for your invaluable (as always) feedback.

Edit: Rerun after clearing Safari's cache and Microsoft User Data (which I have no idea what it is, nor does its loss ever seem to make any kind of difference)...

#2 was faster than #1, but only by a nominal and surprising 30 sec.

(I'll rerun both scans when I'm off-line, but I'm certain that what I've posted is accurate.)

Edit: Could the apparent anomaly have anything to do with the differences in "top's" %CPU and Time figures for the two scans?

Just reran #1 - 413 sec (SurfaceSca 10.0% 0:14.24)

and #2 - 413 sec (dd 0.7% 0:00.13)

with similar results.

sudo dd if=/dev/rdisk0s2 of=/dev/null conv=noerror
(Sample...) dd > 25.4% > 0:12.57
3820858880 bytes transferred in 1473.733713 secs (2592639 bytes/sec)

I note that example 3, which was not run to completion, extrapolates to 10,310.14488 secs (171.835776 minutes) for the full 25Gb, close to a staggering 29 hours for my entire 250Gb HD, and that my HD temperature was the highest I've ever seen it while it was running.


aaaand that's what you get when using the default block size of 512 bytes. It's a new call to DD every 1/2 kilobyte - of which there are 448 million on a 250gb HD. Although it surely heated up your CPU, the hard drive probably didn't notice a thing.

You should also note that you were not scanning the entire drive. "s2" refers to a partition on the drive. (though probably your main HFS partition, so MOST of the drive for sure, but can miss BAD things like IO errors in the partition map or boot block)

Latest version of my surface scanner is here if you want to check it out.

Considering the very small overhead involved in doing a properly blocksized scan in bash, I'd expect my script and techtool to be within less than a minute of each other on a full scan of a 250gb drive.

You NEED to remove the "conv=noerr", otherwise dd will not stop on io error.

Hence ctrl-C (if need be).

> Although it surely heated up your CPU, the hard drive probably didn't notice a thing.

My HD temp was the highest I've ever seen it, i.e. 105F on a machine that generally runs in the mid 80's to mid 90's.

I was wondering whether 29 hours at that temp would be harmful?

> You should also note that you were not scanning the entire drive. "s2" refers to a partition on the drive. (though probably your main HFS partition, so MOST of the drive for sure, but can miss BAD things like IO errors in the partition map or boot block)

My post stated that "I threw three different surface scans at a 25Gb partition" (which is my OS X partition, although it's only 25Gb of 250); I used the smaller partition because I was just experimenting.

> You NEED to remove the "conv=noerr", otherwise dd will not stop on io error.

I don't mind its not stopping when it finds an error...morbid curiosity, but have I misunderstood the command?

Will it report an I/O error and keep going, or will it keep going without reporting what it finds?

> Latest version of my surface scanner is here if you want to check it out.

Thanks; I can't promise when, but I'll check it out and let you know how I make out.

> Latest version of my surface scanner is here if you want to check it out.

Thanks; I can't promise when, but I'll check it out and let you know how I make out.

Ok... I give up.

What do I do with it?

Thanks.

I haven't got Stuffit on my deuced Mac(hina); is there another way to access your surface-scanner, and, if not, which Stuffit app do I need to d/l?

Thanks.

Stuffit Expander worked when I tried V1's file.

Thanks, Jon.

I tend to read and believe man pages, until i can prove they're wrong. If you have a known bad disk which can be used to test dd with various options, and can prove that the section i quoted in green is wrong (my 2nd post on page 1), then i'd be extremely interested (and quite surprised).

[i.e., the answer (until proven otherwise) is: yes, dd reports the error instantly AND it continues to chug along... at least that's my interpretation of the words written on the man page.]

I think dd behaves differently than you are expecting. If it hits an error that stumps it (hangs dd, either temporarily or permanently) then ctrl-c won't save you. It'll be blocking in the kernel until it finishes the block it was reading. THEN ctrl-c may stop it. But it's been my experience that unless you're using a very small block size (512 etc) then you're in for an awful long wait, as each disc block (512) may take 1-2 minutes to pass. If your dd block size is 1mb, it could be 20 minutes or more before it releases with ctrl-c. Some block errors never complete and block until killed.

The reason to not use conv=noerror is that if it gets an error (that passes quickly, say one bad disk block in the entire dd block) then it will display the io error to console, but with conv=noerror, it WON'T STOP, and will NOT return an error code when dd finally finishes. This isn't usually how you want it to behave when looking for errors, unless you are trying to count how many you have. (I usually consider one to be more than enough!) If you omit that conv, dd will stop at its first bad block encountered, and will return an error code.

(fyi, dd pads unreadable blocks with zeros if you use conv=noerror)

StuffIt Expander 2010 - 14.0.1. Alternatively The Unarchiver will work too, and weighs in at about 1/10th the size of SE.

ok try this disk image instead. Sorry for me stuffing something is as easy as cmd-S. Making a disk image is entirely more complicated than should be necessary. (I have deleted the previous .SIT file)

Finder needs a nice contextual menu item for "create disk image" that would DMG a folder, or if it was a file, made a folder by the same name, put it in the folder, and DMG'd that. (or is there something like that available you know of?)

It's been my experience that the man pages are usually very accurate, but are often incomplete. Rsync for example is a very large, detailed, accurate page, but is outright missing several important flags.

Yes, i would expect that. I mean, bad blocks can make just logging in or opening a Finder window take 20 minutes. Such pain is not an exclusive feature of Terminal or dd under those circumstances.


All good (for those who wanted that to happen).


I think there's where our preferences differ. In your context (at a work place), you're mainly interested in strict PASS/FAIL type of analysis... so you can swiftly move on to what else needs doing. (i.e., probably tackle another broken machine that's been waiting for your attention).

We folks at home are focused on our sole problem machine (or device), and are more inclined to want to find more details about how badly the disk's condition was degraded... even if it takes a little time. And if it turns out to be a total of 1 or 2 bad blocks... then maybe a quick full erase [to remap] could make the disk last another day or 3, while we wait for FedEx to deliver the replacement. I remember my first one was a doozy... the main boot partition was hosed with hundreds of bad blocks. I was able to determine the count thanks to ditto -V, which i used to salvage what i could (by copying it off to an external). The copying ditto did took around 28 hours (and that was just the /Users folder, IIRC). Bad blocks are a bitch.




True, but /dev/null won't mind in the least "bit".



Yes, there is Compress in Finder's contextual menu. [it makes a zip archive.] We can actually tweak a few of its "features" which get saved into a com.apple.archiveutility.plist in our home library (so we're not monkeying with the system really).

One simple way to access those prefs is to create a symbolic link to it:

That command puts a symlink in our ~/Library/PreferencePanes/ folder, so when we open System Prefs, a new prefpane will appear there. See this article for more info (and pictures): New hidden PrefPanes in Leopard

V1's dmg makes it moot, but thanks for the alternative to Stuffit.

> ok try this disk image instead.

Got it!

Thanks. (As I said, I'll get to it and let you know how it works for me when I get a chance.)

This thread has turned pretty educational; now let's see if I actually understand what you and Hal have been discussing...

> and will NOT return an error code when dd finally finishes.

> (fyi, dd pads unreadable blocks with zeros if you use conv=noerror)

> it will display the io error to console

I think that-all means that:

1.
does not necessarily mean that my partition has no bad blocks?

2. "dd's" padding of unreadable blocks with zeros will result in "records in" = "records out" even if it finds bad blocks?

3. after "dd" finishes its run I have to go to Console to find out if it actually found any bad blocks? (If that's the case, then still none. )

Thanks to both you and Hal for sharing your expertise.

Oh I thought that compress CMM was added by stuffit, and I didn't realize it would do folders too. Does the zip it makes have good backward and sideways compatibility, or will I have problems with someone trying to unzip it on say, windows xp?

But I'd say anyone that wants to know "how bad" the errors on the hard drive are, isn't too interested in the safety of their information

DD should still send io error notices to stderr which should display for you in the same way the number of blocks copied displays. you should also get an io error in the System log in console.

without the conv, you may see something like this:

dd: /dev/disk0: Input/output error
5+0 records in
5+0 records out
5242880 bytes transferred in 41.363104 secs (126753 bytes/sec)

iirc, if you get say one io error, the records in will not count the bad block, so records in will be smaller than records out. (since it's outputting zeros) BTW, 'records' refers to dd blocks, so 1mb blocksize means each record is 1mb.

That also shows the very long delay that you get from encountering a single io error. If you conv=noerror and it runs into a pack of say, 500 bad blocks, you're in for a long wait. Not all errors take a long time to resolve, but most do.

The error in console will be the same as dd: "/dev/disk0: Input/output error"

does not necessarily mean that my partition has no bad blocks?

Yes and no. Since you didn't see any io error notices, there were no bad blocks in the area you scanned. But if you scanned a diskXsY instead of a diskX, then you skipped other partitions, drivers, partition map, and boot block, so I suppose there could be an error in the skipped space. (tho statistically unlikely)

I also consider "slow blocks" to be errors, as they almost always foretell imminent failure. If you just use the one-liner to read the entire HD, it may encounter many slow blocks on the way but will not inform you and will complete without complaint. The surface scan script intentionally scans in small chunks, timing them, and displays notice if it finds a range of blocks that took too long, making it a much better test.

I don't see any error message, so that means dd did not encounter one. [then again, dd wasn't designed to be a "bad block detector" -- so i don't know what its threshold for defining an error is. maybe a disk could still be wonky and return good data very slowly or something. idunno.]



Right. (AFAIK). <-- looks like we're both wrong there. See Virtual1's answer.



Not right. Here again...

When running a command using a *terminal* device, the phrase "standard error output" means the same screen into which you typed the command. (Though redirection to other file descriptors is certainly possible, standard error is always echoed to the screen [when there is one]).

What's really needed here is someone with a known bad disk to do a few runs and then *show* us the results.

I haven't run xp since maybe 2003, and i never did much with it (other than downloading service packs). The only "unusual" thing about OSX zip archives is that they *may* include resource fork and other Mac extended attributes, if the source files had any such content/metadata. But a plain text file (such as your surface_scan.command) should be cleanly extracted anywhere.




Oh, I totally understand where you're coming from. I definitely wouldn't want a single bad block on some hard drive in the next jet i fly on, for example.

But presumably our personal data is backed up... so measuring the degree of damage is just to satisfy our curiosity and desire for more complete knowledge about the extent of a problem. If Quantum disks average 13 bad blocks after 5 years of usage... and Western Digital drives average 47 bad blocks in the same time period... guess which one i'm gonna buy next time i need a new disk? (if all we ever measure is *one* error, then maybe we miss out on a useful part of the picture).

Thanks to both you and V1 for explaining some confusing stuff.

> What's really needed here is someone with a known bad disk to do a few runs and then *show* us the results.

Not me, thank goodness.

Does your "Surface Scanner" generate a time record, as does Terminal, when it's finished its work?

If I'm going to compare it with TT Deluxe>Surface Scan I'll need to know whether I've got to sit here with my eye on my deuced Mac(hina) during both operations in order to get accurate time readings.

Does your "Surface Scanner" generate a time record, as does Terminal, when it's finished its work?

I've considered having it keep samples and generate a basic graph when it's done to see if there are any (downward) spikes encountered during the scan. I'm also just basically curious to see how scan speeds vary across the surface of a disk - I assume there is a change as scanning farther from the center should yield faster data transfer rate.

For now it just has a hardcoded time limit that if the particular pass doesn't complete in time it stops and errors out.

I have a much more sophisticated script that runs here on several machines that have multiple attached drives, that is set to actually monitor speeds and alert me when they drop to 40% of expected or less. I've been getting emails lately though and I'm not sure why...

2010-01-25 02:20:31 WD2: disk1 "(RAID_slice)" Scan speed 19 below acceptable (norm 67)
2010-01-25 02:20:31 WD2: FAIL: dd if=/dev/rdisk1 of=/dev/null count=142 iseek=371472 bs=1048576 > /dev/null

It's always that same drive too. And the two of them are scanning over a dozen total drives. Makes me suspicious of that one. I think what's happening though is it's hitting at the same time as a cronned rsync from the boot drive, and I think that's the "preferred slice" for the mirror to read from, and rsync building its send list is what's causing things to slow down so much.

OK... As I said, I'll run it against TT Deluxe>Surface Scan for comparative purposes when I've got a coupl'a free hours.

Your dmg has been staring back at me from my desktop for the last 7 weeks, but it took the current discussion about cluttered desktops (not that mine is all that bad) to move me to decide to get it out of my sight.

After TechTool Deluxe completed a surface scan of my 25Gb volume in 06:55 I launched surface_scan.command.2010.01.13.A.dmg to run a comparison test...

[Bug False Alarm Report]

After getting to this point with your script



I discovered that both options 2 and 3 defaulted to scanning disk0.

Oops!

[/Bug False Alarm Report]

With no other options available I just timed how long it took your script to scan 25Gb (06:47...8 sec faster than TTD!), but I've absolutely no idea if the two results are comparable.

Thanks, again, for the script, and sorry to have taken so long to get back to you.

According to the table, HD and HD2 are both slices on the same device (disk0). Therefore they share the same (master) partition map... which is the first (some number of) blocks on "disk0". I guess lumping the two "HDs" makes sense from the viewpoint that: if one is bad, then you'll still need to replace both (when a new HD is installed).

But, i should let V1 speak for his own product.

--

EDIT: this forum software doesn't let us put styles (colors, bold, italics, etc.) inside code tags. What a drag.

EDIT#2: and that first edit took almost 5 minutes to reload [in contrast to places like macosxhints or macrumors, where the pages fly open... even with hundreds of members logged in (and perhaps thousands of guests lurking), while dozens of users are posting almost simultaneously.]

It's listing all the available character devices for scanning. Each physical disk normally shows up at least twice, once for the entire device, ("disk0") and once for each formatted HFS+ partition on it. ("disk0s2", "disk0s5", etc)

This allows you to surface scan an unformatted disk, as well as to scan a specific disk by volume name if you don't know the device number.

In any event, no matter which "disk0" you select, it will scan the entire disk0 device.

In the past it was set up to only scan the specific partition if you selected one, but I decided that was silly since you really need to know if the entire drive the volume is on is bad, not just to see if there's an error on the specific partition. (since an error ANYWHERE on the drive can cause it to beachball when accessing ANY partition on the drive) My philosophy is that a drive with even one slow block or one bad block needs to be replaced immediately.

I also discovered a pleasant surprise the other day -- apple's hardware test disks, when you select to do a full disk scan, will check for slow blocks in addition to bad blocks. So for my purposes, that's probably as acceptable of a check as my script.

Regarding your edits, especially the 2nd, please post such comments in FineTunedMac Feedback. That way threads like this won't get derailed with off-topic discussion and you increase the likelihood tacit will see your observations/complaints.

The instant I saw Hal's post I realized that I was so hell-bent on comparing scan times for my HD partition that I breezed right past the "DEVICE" (not "device," mind you, but "DEVICE") thing. (See my sig for more.)

My bad. Sorry.

> In the past it was set up to only scan the specific partition if you selected one, but I decided that was silly since you really need to know if the entire drive the volume is on is bad, not just to see if there's an error on the specific partition. (since an error ANYWHERE on the drive can cause it to beachball when accessing ANY partition on the drive)

...which makes you wonder why AHT allows you to scan partitions one-at-a-time?