1

I'm using the command to copy CDROM image:

# dd if=/dev/sr0 of=./maverick.iso

But it's very slow, at about 350k bytes/sec. I've searched the google, and try the command

# hdparm -vi /dev/sr0

/dev/sr0:
 HDIO_DRIVE_CMD(identify) failed: Bad address
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device

 Model=DVD-ROM UJDA775, FwRev=DA03, SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=yes, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 *udma2 
 AdvancedPM=no
 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3:  ATA/ATAPI-1,2,3,4,5

 * signifies the current active mode

Seems like DMA is already on.

And a device test gives:

# hdparm -t /dev/sr0 

/dev/sr0:
 Timing buffered disk reads:    2 MB in  6.58 seconds = 311.10 kB/sec

# sudo hdparm -tT /dev/sr0 

/dev/sr0:
 Timing cached reads:     2 MB in  2.69 seconds = 760.96 kB/sec
 Timing buffered disk reads:  m  4 MB in  5.19 seconds = 789.09 kB/sec

The CD-ROM device and disc should be okay because I can copy it very fast in Windows, using UltraISO utility.

So I guess there is something not configured right in Ubuntu, is it?

1
  • If you value your time, do not use dd for imaging optical media, use k3b instead, which will spin at the highest speed supported by the drive and media. Any answers suggesting different block sizes won't help. This is now 2018 and nothing changed. In k3b use Tools/Copy Medium, set to Image Only, and type in destination file name.
    – ajeh
    Jul 20, 2018 at 0:05

2 Answers 2

2

You're using dd incorrectly.

The block size for dd is 512 bytes by default, which is acceptable (but not great, more on that later) for a hard drive since hard drive sectors are 512 bytes in size. CD-ROMs, however, have a sector size of between 2048 and 2352 bytes. The default block size causes the drive to do four or five partial reads per sector, slowing it down immensely.

The other things to factor in are the access timing and the drive buffer. To make a long story short, instead of reading sector-by-sector, you should read large chunks. I don't know what the buffer size of the drive is, but 32 megabytes is generally a decent block size.

# dd if=/dev/sr0 of=./maverick.iso bs=32M
4
  • I have tried 16M and 32M block sizes, it's around 980k bytes/sec, it's still slow.
    – Lenik
    Dec 23, 2010 at 3:49
  • Block size makes absolutely no difference, because when using dd on the optical drive device, it does not spin up to the proper speed. Larger block size won't help if the drive does not spin up. I don't downvote, so this is just a comment.
    – ajeh
    Jul 20, 2018 at 0:07
  • @ajeh: I've never had it not spin up to full speed, so I don't understand what you're saying. Jul 20, 2018 at 0:23
  • Great that you are not affected. Not everyone is so fortunate.
    – ajeh
    Jul 21, 2018 at 14:52
1

It's on UDMA2, so there should be nothing to configure. It might be more simple than that: Have you tried using bs=2M on your dd command? (You might have to try a few to find the optimal size for CD-ROM, if it gets too large the CD will spin down. dd doesn't use overlapped i/o.) Longer reads should get faster.

5
  • Well, set a 2M block size doesn't improve speed. Do you know how to clear the read cache (as opposed to flush the write cache by sync command), so I can have a test on different block sizes?
    – Lenik
    Dec 23, 2010 at 2:20
  • Cycling the tray should clear all caches. Dec 23, 2010 at 2:21
  • Should I must cycling the tray? My test script is: for bs in 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 8M 16M 32M 64M; do sync; echo block size: $bs; /bin/dd if=/dev/sr0 of=m.iso bs=$bs count=30; done
    – Lenik
    Dec 23, 2010 at 2:23
  • eject can open and close the tray. (Different drives respond differently, try -r, -t, and -T.) There is probably another way to dump the cache, I just don't know it. Dec 23, 2010 at 2:30
  • No, eject doesn't close the tray on laptop.
    – Lenik
    Dec 23, 2010 at 3:16

You must log in to answer this question.

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