0

I ran the command

sudo dd if=/dev/disk# of=/Volumes/Path/To.iso

at about 6am this morning. It's now almost 2pm and the command is still running. The cdr input image is about 300GBs.

I have a Late 2012 Mac Mini Server, 2.6 GHz i7, 16GB 1600 MHz DDR3, Intel HD Graphics 4000 1536 MB. And I'm running up to date Mojave.

This seems really really slow to me.

I first tried using hdutil but it kept throwing an error.

  • Are you reading from an internal disk or an external one, HDD or SSD? Same for writing. – nohillside Dec 24 '18 at 21:29
  • Oh, good point, both images are on an external HDD & that drive is daisy chained with firewire8. That mighta made a difference, lol. – Kerlix Dec 25 '18 at 5:36
  • What do you mean by "cdr"? It's definitely not a CD-R if it's 300 GB, and that's the only thing I could think of. Edit: Wait, I think I got it. – Zenexer Jan 6 at 8:01
  • If this question is still relevant for you: please look through the comments and the existing answers, then edit the question to add necessary details. Right now we can only guess what your intentions are, and what problem you are facing. – nohillside Jan 6 at 14:18
1

It usually doesn't take long to rip a CD-R to an ISO. Depending on how it's done, a CD-R in decent condition should take about 15-45 minutes, with 20-30 minutes being what I would normally expect. It can take significantly longer if the disk is scratched or the material within it is deteriorating, which can happen over time. This is because your drive and/or computer need to perform error correction. It might take an hour or two, but it wouldn't take a full day.

Double-check that the disk you’re copying from is actually the CD-R drive. Check to see how large the output file is: if it’s larger than what you expect it to be, you may be copying from the wrong drive.

It’s possible that the disk is too damaged to be read properly. This might cause the error you were getting with your original command. dd might not be aware of the situation and may just hang. If this happens, you’ll see the output file steadily grow in size, then suddenly stop. dd will look like it’s still running, but no data will be added, or it’ll be added very slowly.

  • If you're going to downvote, I'd greatly appreciate suggestions. – Zenexer Jan 6 at 8:16
  • 2
    If you need to guess, or expect the OP to clarify their question, it is be better to use the comments beneath the questions first to ask for clarification. – nohillside Jan 6 at 10:26
  • @nohillside Generally I do, but I’m fairly certain I understand what’s going on here. – Zenexer Jan 6 at 10:27
  • /dev/disk# could very well be a CD drive, and the CD in the drive may contain only 300 GB of data written to it. – nohillside Jan 6 at 10:28
  • 1
    You got me on that :-) Could still be a typo though. Let's see whether they come back to clarify – nohillside Jan 6 at 10:30
1

Adding a large buffer will speed things up significantly. The default size is small; like 512 bytes. You increase the size by using the bs option. I'm only using sudo because you did.

sudo dd if=/dev/disk bs=4096m | sudo dd of=/Volumes/Path/To.iso bs=4096m

This scary looking command will ask the dd commands to report back their status. The -s says to signal.

sudo kill -s siginfo $(pgrep ^dd)   # get dd info

I did testing with various buffer sizes, the larger the buffer the faster will be the copy. Don't want to get so big a buffer as the buffer needs to be paged.

If I got the syntax above wrong, these are the actual commands that have worked for me. I assume you know that you need to unmount the partition/drive before using dd. For some dd commands, I needed to use sudo.

dd if=/dev/disk0s10 bs=4096m | gzip | dd of=~/disk0-s10 bs=4096m
dd if=~/disk0-s10 bs=4096m | gunzip | dd of=/dev/disk0s10 bs=4096m
sudo kill -s siginfo $(pgrep ^dd)   # get dd info

Edit: Jan 18,2019 I did timings using one or two dd commands. It was a toss-up of which form was faster. The time in my test varied typically by 0.3 of a second between the commands. However, in one case the two dd commands were slower by over a second. The difference seemed to be which command was run first. The second test was always faster. I'm guess that the one dd command build a second process to output the data and communicates to the second process via a pipe. This is about the same as using two dd commands.

dd if=InstallESD.dmg bs=801920k  of="/Volumes/--Mojave--/mojave2.dmg" 
5+1 records in
5+1 records out
4719681368 bytes transferred in 28.887363 secs (163382216 bytes/sec)
Show_Time
 date +%s 
  Elapsed time in seconds since start of processing: 84    Time of this step: 29

dd if=InstallESD.dmg bs=801920k | dd of="/Volumes/--Mojave--/mojave.dmg" bs=801920k
5+1 records in
5+1 records out
4719681368 bytes transferred in 27.383548 secs (172354633 bytes/sec)
0+72017 records in
0+72017 records out
4719681368 bytes transferred in 27.459524 secs (171877757 bytes/sec)
Show_Time
 date +%s 
  Elapsed time in seconds since start of processing: 112    Time of this step: 28

rm  "/Volumes/--Mojave--/mojave.dmg"
rm  "/Volumes/--Mojave--/mojave2.dmg"
Show_Time
 date +%s 
  Elapsed time in seconds since start of processing: 112    Time of this step: 0

dd if=InstallESD.dmg bs=801920k  of="/Volumes/--Mojave--/mojave2.dmg" 
5+1 records in
5+1 records out
4719681368 bytes transferred in 26.754509 secs (176406950 bytes/sec)
Show_Time
 date +%s 
  Elapsed time in seconds since start of processing: 139    Time of this step: 27

dd if=InstallESD.dmg bs=801920k | dd of="/Volumes/--Mojave--/mojave.dmg" bs=801920k
5+1 records in
5+1 records out
4719681368 bytes transferred in 26.210222 secs (180070255 bytes/sec)
0+72017 records in
0+72017 records out
4719681368 bytes transferred in 26.286946 secs (179544682 bytes/sec)
Show_Time
 date +%s 
  Elapsed time in seconds since start of processing: 165    Time of this step: 26

... lines at the beginning were trimmed. ...

Here is the bash script I used.

#!/bin/bash -v

function Show_Time () {
  let currentRunTime="$( date +%s ) - ${Seconds_since_the_epoch_start}"
  let stepRunTime=currentRunTime-previousRunTime
  echo "  Elapsed time in seconds since start of processing: ${currentRunTime}" \
     "   Time of this step: ${stepRunTime}"
  echo
  let previousRunTime=currentRunTime
}

savedCommandName="$0"
echo
echo "${savedCommandName} script last revised on $(GetFileInfo -m $0)"
#echo "${savedCommandName} script revised."
echo
# input file name  "/Applications/InstallmacOSHighSierra.app/Contents/SharedSupport/InstallESD.dmg"
inputDir="/Applications/InstallmacOSHighSierra.app/Contents/SharedSupport"
cd ${inputDir}
inputName="InstallESD.dmg"
echo "inputDir is ${inputDir}"
echo "inputName is ${inputName}"
ls -l "${inputDir}/${inputName}"

ls -l "/Volumes/--Mojave--/mojave.dmg"
rm "/Volumes/--Mojave--/mojave.dmg"
ls -l "/Volumes/--Mojave--/mojave.dmg"

ls -l "/Volumes/--Mojave--/mojave2.dmg"
rm "/Volumes/--Mojave--/mojave2.dmg"
ls -l "/Volumes/--Mojave--/mojave2.dmg"
# Set the start time now that the user interaction is done
Seconds_since_the_epoch_start=$( date +%s )
# 80meg buffer


Show_Time
dd if=InstallESD.dmg bs=801920k  of="/Volumes/--Mojave--/mojave2.dmg" 
Show_Time
dd if=InstallESD.dmg bs=801920k | dd of="/Volumes/--Mojave--/mojave.dmg" bs=801920k
Show_Time
rm  "/Volumes/--Mojave--/mojave.dmg"
rm  "/Volumes/--Mojave--/mojave2.dmg"
Show_Time
dd if=InstallESD.dmg bs=801920k  of="/Volumes/--Mojave--/mojave2.dmg" 
Show_Time
dd if=InstallESD.dmg bs=801920k | dd of="/Volumes/--Mojave--/mojave.dmg" bs=801920k
Show_Time
rm  "/Volumes/--Mojave--/mojave.dmg"
rm  "/Volumes/--Mojave--/mojave2.dmg"
Show_Time
dd if=InstallESD.dmg bs=801920k  of="/Volumes/--Mojave--/mojave2.dmg" 
Show_Time
dd if=InstallESD.dmg bs=801920k | dd of="/Volumes/--Mojave--/mojave.dmg" bs=801920k
Show_Time
  • +1 for the good answer. – Allan Dec 24 '18 at 21:48
  • 5
    While @Allan might consider this a good answer I do not. Technically the bs operand is block size not "buffer size" and while using an increased block size can decrease the overall time frame nonetheless the command you are suggesting sudo dd if=/dev/disk bs=4096m | sudo dd of=/Volumes/Path/To.iso bs=4096m is malformed! There is no benefit to piping dd to itself as you've done in this command! – user3439894 Dec 24 '18 at 23:36
  • I believe it solved the original posters issue. I'm cautious here. I went with things that I have tested. I know bs is block size, but I thought that terminology would be confusing. – historystamp Dec 26 '18 at 23:10
  • I thought it was SIGUSR1 that caused dd to give a signal. – wizzwizz4 Jan 7 at 14:11

Not the answer you're looking for? Browse other questions tagged .