Great article/howto for those who need iso/cdrecord help on linux

[MasterSamwise]

Burning CD's on Linux

This should be very helpful. It Took me about a half hour to find. (I wasn't looking in the right places). Pretty soon I was burning an ISO Image on to a disk. And hell, if i wanted to I could make my own ISO! Have fun.

Peace Out
Master Sam

 

[Barnaby W. Füi]

this is the one I learned from, I always thought it did a fairly good job.

 

[drag]

Here's how I do it.

dd if=/dev/cdrom of=thecd.iso

then

cdrecord dev=0,0,0 speed=40 thecd.iso

But thats only for copying a cd, not making your own image...
(and i am not realy sure that it works, been a long timesince I tried it.)


Very imformative MasterSamwise, thanks

 

[manly]

Originally posted by: BingBongWongFooey
this is the one I learned from, I always thought it did a fairly good job.

Agreed, the CD Writing HOWTO is an excellent superset of this thin DeveloperWorks article.

drag,
Since you listed 40X burning speed, do you have any insight on various problems I see with CD writing under Linux:
http://forums.anandtech.com/messageview.cfm?catid=33&threadid=970785&FTVAR_MSGDBTABLE=arc

 

[Barnaby W. Füi]

BTW you can stick some variable definition in your shell init scripts, and burn with a simple cdrecord file.iso

 

[manly]

I'll bump this thread for the curious.

Not long after posting my CD writing rant thread (linked above), I upgraded to cdrecord 2.0 (and friends).

The good news is cdrecord 2.0 supports direct writing to ATAPI CD-RW devices (no longer requiring IDE SCSI emulation). The bad news is the problems I experienced with mkisofs and high-speed burning performance don't seem to have been mitigated any.

I haven't done extensive testing, but mkisofs seems to be just as slow as before (oh say good enough to feed cdrecord at around 16X without stalling the pipe).

cdrecord still seems to suffer if I try to ramp up the writing speed. 24X or higher basically destroys interactive system response, but surprisingly does not result in a coaster or any real adverse problems.

Strangely enough, burning at 48X, system response is basically completely gone, and the resulting average writing speed (on one test) of an ISO is 17.3x. Burning at 24X, system response is still very poor but I can mostly switch between applications and the GUI eventually responds (at 48X, basically nothing is responsive). Average writing speed of just one test of the same ISO is 19.2x.

The only difference so far is that w/ the "ATA Packet interface" I can enable DMA transfers on the CD-RW device without causing cdrecord to hang. This should be very useful if cdrecord were reliable at high-speed burning. See my previous rant thread for a reference to this problem. The only catch is cdrecord issues this ominous warning:

Warning: The related libscg interface code is in pre alpha.
Warning: There may be fatal problems.

For the record, the test system is an old Pentium3 800 MHz PC with a supposedly performant IDE disk subsystem (an add-on PCI ATA-133 controller and a fast 7200 RPM disk drive). I've used the system enough under to Linux to be pretty sure disk I/O is not the problem, although I haven't run bonnie to find out for sure (I have tested transfer rate with hdparm and throughput appears to be in order). Besides, CD writing under Windows is trivial at high speeds on this PC. In the meantime, I always use 12X write speed (10X for rewritable media), and all is well.

If anyone has positive experiences with high-speed CD writing under Linux, I'd like to hear about it. With any luck, Linux 2.6 will be out by the end of the year.

 

[Chaotic42]

Wow, manly, I've never had any problems at all with cdrecord, mkisofs, or mkhybrid. I'm using a 40x12x48 TDK burner. I do, however, have a dually system. That might explain the smoothness of the system, but my average burn speeds are always pretty high.

I'm using kernel 2.4.20.

 

[manly]

Chaotic42,

Inspired by your positive response, I decided to play with it a bit more.

I tuned my IDE drives just a bit more with hdparm, and have mitigated the problems. Specifically, I enabled interrupt unmasking, which was probably the cause of poor interactive system response during intensive disk I/Os (only when writing a CD, not generally). Throughput wasn't the problem, but apparently, the kernel was pretty much ignoring everything else while mkisofs and cdrecord were streaming away. I also enabled 32-bit I/O support, which is supposed to be a solid performance win.

With just those changes (DMA transfers is already enabled by the kernel for hard disk drives), mkisofs sped up by a substantial amount. Offhand, it worked fast enough to average nearly 32X write speed (when sending the output directly to /dev/null). I'm curious if you're able to master a 700 MB ISO in significantly less time than 2:45 with mkisofs.

So in an actual write test at 24X, the results were significantly better than previously. The system was still usable, and there were no buffer underruns. It turns out this write speed is 24X CLV, so a 700 MB disk is burned in a brief 3:40 or so.

However, in a write test at 48X (what should be CAV), mkisofs was not fast enough to prevent some buffer underruns. The system was also noticeably less responsive (but still much better than in my previous tests). Because at this writing speed, mkisofs was stalling the pipe, the overall writing time was only slightly better than the 24X trial.

I haven't tried 32X yet, but I'm not all that interested in saving 10 seconds of time by pushing the apparent limits of my current system. Maybe when I have a better PC, I'll experiment with a different/newer distro.

I'm still puzzled why mkisofs is relatively sluggish; it doesn't appear to be CPU bound, and I'm nowhere near the practical limits of disk throughput. I also wonder what effect the so-called low-latency patch (or similar) would have on CD burning, if any.