This is more of a rant thread, but maybe someone will have a brilliant solution to dispel any notions I have.
Basically, I've been using the mkisofs + cdrecord combo for a while now, and it does everything I need. Sure it isn't quite as convenient as the typical Windows GUI, but when in Rome, do as the Romans do. 😉 Actually, I tried Xcdroast a while ago and thought they need to actually put some effort in usability and UI design, so I went back to the CLI. With mkisofs' graft-points and path-list options, the combo is full featured for my needs.
Anyhow, I recently replaced a reliable 12X burner with a 48X burner (fully knowing the best I'd get is about a twofold improvement in burn times). However, I had poor results burning at anything faster than 16X: the burner's buffer would constantly overrun. Last night I determined mkisofs wasn't working fast enough and it essentially was stalling the pipe into cdrecord. In popular parlance, I burn "on the fly". In an isolated test, mkisofs was taking just over 3 minutes to master a (single-file) 650 MB ISO and sending the results to /dev/null. This comes out to a piddling 3 MB/s. According to hdparm, the IDE subsystem is good for at least 33 MB/s, and I don't think the ext3 filesystem is particularly fragmented (this isn't NTFS).
Having isolated the problem, I then discovered a problem with cdrecord. By burning from an ISO image file (rather than piped from mkisofs), I can avoid buffer underruns at up to 48X burn speeds. However, once the burner hits approx. a 30X writing rate, interactive system response is almost completely destroyed. It takes seconds for events to register and for the UI to update. I've never had latency/response problems with Linux 2.4 but imagine the standard complaints (w/o the low latency patch) magnified by a couple orders of magnitude. However, the CD write will successfully complete and the system behavior reverts to normal. Enabling DMA on the IDE device underlying the ide-scsi device does not help the situation.
I just tried the analogous procedure with cdrdao at 40X and experienced the same problem: once the speed ramps up, the moderately-loaded system continues to function but interactive response is virtually shut down. Worse off, cdrdao does exhibit constant buffer underruns at a high write speed.
I did just a bit of research, and it appears Linux CD writing just hasn't been optimized for the latest high-speed burners. Judging from the following post, some of the problems I encountered perhaps won't go away until Linux 2.6 is released (I'm not about to run a 2.5 devel kernel just for kicks):
http://lwn.net/Articles/13538/
I'm not sure why mkisofs is so slow though, and if it's not just an isolated incident on my system, then it's effectively the bottleneck for on-the-fly data CD writing.
I'm just curious if anyone has had good results with high-speed burners (32X or faster) on free *nix systems, since mkisofs and cdrecord are the standard tools. For the record, my system runs SuSE Linux 8.0 and the vendor's kernel 2.4.18.
Basically, I've been using the mkisofs + cdrecord combo for a while now, and it does everything I need. Sure it isn't quite as convenient as the typical Windows GUI, but when in Rome, do as the Romans do. 😉 Actually, I tried Xcdroast a while ago and thought they need to actually put some effort in usability and UI design, so I went back to the CLI. With mkisofs' graft-points and path-list options, the combo is full featured for my needs.
Anyhow, I recently replaced a reliable 12X burner with a 48X burner (fully knowing the best I'd get is about a twofold improvement in burn times). However, I had poor results burning at anything faster than 16X: the burner's buffer would constantly overrun. Last night I determined mkisofs wasn't working fast enough and it essentially was stalling the pipe into cdrecord. In popular parlance, I burn "on the fly". In an isolated test, mkisofs was taking just over 3 minutes to master a (single-file) 650 MB ISO and sending the results to /dev/null. This comes out to a piddling 3 MB/s. According to hdparm, the IDE subsystem is good for at least 33 MB/s, and I don't think the ext3 filesystem is particularly fragmented (this isn't NTFS).
Having isolated the problem, I then discovered a problem with cdrecord. By burning from an ISO image file (rather than piped from mkisofs), I can avoid buffer underruns at up to 48X burn speeds. However, once the burner hits approx. a 30X writing rate, interactive system response is almost completely destroyed. It takes seconds for events to register and for the UI to update. I've never had latency/response problems with Linux 2.4 but imagine the standard complaints (w/o the low latency patch) magnified by a couple orders of magnitude. However, the CD write will successfully complete and the system behavior reverts to normal. Enabling DMA on the IDE device underlying the ide-scsi device does not help the situation.
I just tried the analogous procedure with cdrdao at 40X and experienced the same problem: once the speed ramps up, the moderately-loaded system continues to function but interactive response is virtually shut down. Worse off, cdrdao does exhibit constant buffer underruns at a high write speed.
I did just a bit of research, and it appears Linux CD writing just hasn't been optimized for the latest high-speed burners. Judging from the following post, some of the problems I encountered perhaps won't go away until Linux 2.6 is released (I'm not about to run a 2.5 devel kernel just for kicks):
http://lwn.net/Articles/13538/
I'm not sure why mkisofs is so slow though, and if it's not just an isolated incident on my system, then it's effectively the bottleneck for on-the-fly data CD writing.
I'm just curious if anyone has had good results with high-speed burners (32X or faster) on free *nix systems, since mkisofs and cdrecord are the standard tools. For the record, my system runs SuSE Linux 8.0 and the vendor's kernel 2.4.18.
