An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
Surface scan doesn't run from Terminal?
#7283 01/05/10 08:05 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
artie505 #7303 01/05/10 10:54 PM
Joined: Sep 2009
Offline

Joined: Sep 2009

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.

Re: Surface scan doesn't run from Terminal?
artie505 #7304 01/05/10 11:16 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
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.


I work for the Department of Redundancy Department
Re: Surface scan doesn't run from Terminal?
Virtual1 #7309 01/05/10 11:42 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: Virtual1
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?

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:

Originally Posted By: man dd
conv=noerror

Do not stop processing on an input error. When an input error occurs, a diagnostic message followed by the current input and output block counts will be written to the standard error output in the same format as the standard completion message.

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).

Last edited by Hal Itosis; 01/05/10 11:45 PM.
Re: Surface scan doesn't run from Terminal?
Hal Itosis #7332 01/06/10 04:48 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
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:
Code:
Service-Right:~ root # system_profiler SPFireWireDataType
FireWire:

    FireWire Bus:

      Maximum Speed: Up to 800 Mb/sec

        Unknown Device:

          Manufacturer: OWC Mercury Elite
          Model: 0x0
          GUID: 0x23A409E010D860
          Maximum Speed: Up to 800 Mb/sec
          Connection Speed: Up to 800 Mb/sec
          Sub-units:
            Unknown Unit:
              Unit Software Version: 0x10483
              Unit Spec ID: 0x609E
              Firmware Revision: 0x103
              Product Revision Level: GKAO
              Sub-units:
                Unknown SBP-LUN:
                  Capacity: 1 TB (1,000,204,886,016 bytes)
                  Removable Media: Yes
                  BSD Name: disk1
                  Partition Map Type: GPT (GUID Partition Table)
                  S.M.A.R.T. status: Not Supported
                  Volumes:
                    OWC800:
                      Capacity: 999.86 GB (999,860,912,128 bytes)
                      Available: 938.89 GB (938,889,232,384 bytes)
                      Writable: Yes
                      File System: Journaled HFS+
                      BSD Name: disk1s2
                      Mount Point: /Volumes/OWC800

        Built-in Hub:

          Maximum Speed: Up to 800 Mb/sec
          Connection Speed: Up to 800 Mb/sec

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?)

Last edited by Virtual1; 01/06/10 05:45 PM. Reason: more Science!

I work for the Department of Redundancy Department
Re: Surface scan doesn't run from Terminal?
Virtual1 #7428 01/11/10 08:32 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
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. smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
artie505 #7435 01/11/10 07:31 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: artie505
> 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

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

Re: Surface scan doesn't run from Terminal?
artie505 #7437 01/11/10 08:11 PM
Joined: Aug 2009
Likes: 3
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 3

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.



dkmarsh—member, FineTunedMac Co-op Board of Directors
Re: Surface scan doesn't run from Terminal?
dkmarsh #7452 01/12/10 08:04 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
I dunno...

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

The break command is equivalent to entering Control + C on the command line.

(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. confused frown

(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.)


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
artie505 #7453 01/12/10 08:20 AM
Joined: Sep 2009
Offline

Joined: Sep 2009
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]


Last edited by Hal Itosis; 01/12/10 08:31 AM.
Re: Surface scan doesn't run from Terminal?
Hal Itosis #7454 01/12/10 10:25 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Thanks for trying to unravel this... smile
Quote:
Artie-s-Computer-4:~ artie$ stty -e
speed 9600 baud; 50 rows; 100 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
discard dsusp eof eol eol2 erase intr kill lnext
^O ^Y ^D <undef> <undef> ^? ^C ^U ^V
min quit reprint start status stop susp time werase
1 ^\ ^R ^Q ^T ^S ^Z 0 ^W
Artie-s-Computer-4:~ artie$

Unfortunately, "du" doesn't run long enough for me to have enough time to enter ^C, so I did this:
Quote:
Last login: Tue Jan 12 05:08:13 on ttys000
Artie-s-Computer-4:~ artie$ diskutil repairPermissions /
Started verify/repair permissions on disk disk0s2 HD
[ | 0%..10%..20%......................................... ] ^C
Artie-s-Computer-4:~ artie$

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

Does that first command's output tell you anything?


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
Hal Itosis #7455 01/12/10 10:36 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Oops...forgot the echo $? part:
Quote:
Artie-s-Computer-4:~ artie$ diskutil repairPermissions /
Started verify/repair permissions on disk disk0s2 HD
[ | 0%..10%..20%......................................... ] ^C
Artie-s-Computer-4:~ artie$ echo $?
130
Artie-s-Computer-4:~ artie$

What does that-all mean?

Last edited by artie505; 01/12/10 10:37 AM. Reason: What...

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
Hal Itosis #7456 01/12/10 11:08 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
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. smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
artie505 #7475 01/12/10 07:44 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
> 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.


I work for the Department of Redundancy Department
Re: Surface scan doesn't run from Terminal?
artie505 #7486 01/12/10 10:03 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: artie505
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. smile

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.

Originally Posted By: artie505
Unfortunately, "du" doesn't run long enough for me to have enough time to enter ^C,

Must be a really tiny home folder, or a really (really!) fast Mac... or both.
Here's my (slow) PowerBook G4...
Code:
$ time du -sh ~
2.8G	/Users/halito

real	0m9.342s
user	0m0.411s
sys	0m6.104s

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


Originally Posted By: artie505
What does that-all mean?

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).


Last edited by Hal Itosis; 01/12/10 10:42 PM.
Re: Surface scan doesn't run from Terminal?
Virtual1 #7618 01/17/10 08:28 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
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?"


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
Virtual1 #7619 01/17/10 08:33 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
> 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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
artie505 #7620 01/17/10 08:37 AM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: artie505
And can anybody explain why TechTool Deluxe's "surface scan" is so much faster than "dd?"

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

Re: Surface scan doesn't run from Terminal?
Hal Itosis #7625 01/17/10 09:27 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
> 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.

Code:
Artie-s-Computer-4:~ artie$ time du -sh ~
233M	/Users/artie

real	0m0.162s
user	0m0.011s
sys	0m0.077s
Artie-s-Computer-4:~ artie$

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. smile

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)...

Code:
Artie-s-Computer-4:~ artie$ time du -sh ~
 59M	/Users/artie

real	0m0.049s
user	0m0.010s
sys	0m0.038s

Last edited by artie505; 01/17/10 12:26 PM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
Hal Itosis #7626 01/17/10 09:35 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Originally Posted By: Hal Itosis
Originally Posted By: artie505
And can anybody explain why TechTool Deluxe's "surface scan" is so much faster than "dd?"

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

#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?

Last edited by artie505; 01/17/10 09:43 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
Hal Itosis #7629 01/17/10 11:01 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Just reran #1 - 413 sec (SurfaceSca 10.0% 0:14.24)

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

with similar results.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
artie505 #7658 01/18/10 12:36 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
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.


I work for the Department of Redundancy Department
Re: Surface scan doesn't run from Terminal?
Virtual1 #7669 01/18/10 04:16 AM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: Virtual1
You NEED to remove the "conv=noerr", otherwise dd will not stop on io error.

Hence ctrl-C (if need be).

Re: Surface scan doesn't run from Terminal?
Virtual1 #7676 01/18/10 07:44 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
> 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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Surface scan doesn't run from Terminal?
Virtual1 #7678 01/18/10 08:04 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
> 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.

Last edited by artie505; 01/18/10 08:22 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Page 1 of 2 1 2

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.064s Queries: 65 (0.053s) Memory: 0.7316 MB (Peak: 0.9333 MB) Data Comp: Zlib Server Time: 2024-03-28 19:16:42 UTC
Valid HTML 5 and Valid CSS