cdrwtool in Debian: maxing out the CPU doing a simple CD-RW quick blank

Shm00nix · 07-22-2009, 08:46 PM

After installing 'udftools' on my 'kernel 2.6.18-4-686' Debian desktop system and following the clear, simple and logical directions in '/usr/share/doc/udftools/README.Debian.gz' (it seems that great progress has been made in both software and documentation since the last time I tried this), I attempted to prepare a CD-RW blank for packet-writing on an older "LG" CD-RW internal EIDE drive. Setting up '/dev/pktcdvd' to reference my '/dev/hdd' was as easy as running '/etc/init.d/udftools start', as per the README. However as per the README as well, when I run:

# cdrwtool -d /dev/hdd -q

and after I get this dialog:

using device /dev/hdd
1331KB internal buffer
setting write speed to 12x
Settings for /dev/hdd:
Fixed packets, size 32
Mode-2 disc

I'm going to do a quick setup of /dev/hdd. The disc is going to be
blanked and formatted with one big track. All data on the device
will be lost!! Press CTRL-C to cancel now.
ENTER to continue.

Initiating quick disc blank
Disc capacity is 295264 blocks (590528KB/576MB)
Formatting track

the program appears to max out the CPU use of my system almost right away: pretty much freezing everything on my desktop in its tracks (except the HW mouse), until it appears to approach the end of blanking the CD-RW disk -- @ 17 minutes -- where I get the error message:

wait_cmd: Input/output error
Command failed: 04 17 00 00 00 00 00 00 00 00 00 00 - sense 03.0c.00
format disc: Input/output error

and then my system returns to normal.

At this point I don't have a clue as to the problem. What to do...

GrapefruiTgirl · 07-23-2009, 02:10 PM

Wow, sure does look a lot simpler to set up than it was when I first set up packet writing.

I do remember, it took a long time to blank or format a UDF disc; 17 mins seems about right, give or take half an hour, and the system was definitely 'busy' though not maxed out. What I wonder is whether or not, and how, the in-kernel setting for how many buffers to allocate for packet-writing affects the actual performance. Any chance you know what that setting is on your kernel (you can probably locate it in the .config for the kernel)? Though now that I think of it, there shouldn't really be that much computer<-->drive traffic for a simple blank

As for it quitting near the end, the only times (I think) that happened for me is when using crappy old media, or the lens in the drive is dirty. Either case makes the blank/format quit prematurely. Better/newer media and cleaning the lens are the obvious choices in these cases

FWIW, it took me a lot of fiddling with my blank/format commands before I got it to go the whole way through, so here's the commands I use (the man page will explain the switches for you) as well as a few other burning odds and ends I keep in a little tutorial nearby at all times:

Code:

Identifying SCSI-bus devices / CDRW devices:
cdrecord -scanbus
cdrecord dev=ATAPI -scanbus

BLANK a CDRW (fast basic blank):
cdrecord dev=0,0,0 speed=10 blank=fast padsize=63s -pad -dao -v -eject

FORMAT a blank CD-RW disc for UDF packetwriting:
(root)# cdrwtool -d /dev/hdb -q -b full -v 0x0102 -t 4 -l 3

BURNING an ISO image to CD:
(root)# cdrecord dev=/dev/hdd speed=4 padsize=63s -pad -dao -v -eject /absolute/path/to/image.iso

For BLANK and BURN in one command: add 'blank=fast' to the above command.


RAWREAD: to create/check/compare the md5sum of a CD & ISO:
rawread /dev/cdrom > myiso.iso <-- make ISO file from a CD
rawread /dev/cdrom | md5sum    <-- The CD's md5sum
md5sum myiso.iso               <-- The ISO file's md5sum


Blanking a CDRW in the SATA Pioneer DVD Drive:
(I don't know why this works..)
-- Blank=all works too.

cdrecord dev=ATAPI:0,0,0 speed=10 blank=fast padsize=63s -pad -dao -v -eject


Burning a (bootable) DVD image .ISO to disc (like the Slack64-current DVD):

growisofs -speed=2 -dvd-compat -Z /dev/sr0=imagefile.iso

Note that depending on the actual command you are issuing, and the type of drive, the /dev= can refer to either the name (like hda) or to the SCSI address (like 0,0,0) even though cdrecord will complain about you using the name method, it still works fine.

Good luck, I hope you figure it out

Sasha