Hi:
Scenario: I am running cdrecord in order to burn an iso image onto a disk. And in the middle of the session an LQ post arrives at my machine. Am I at risk of cdrecord failing?

I cannot think why the burning of iso image will be afected by a LQ post. Can you think of any reason why this should be so?

Yes. Burning a disk is an uninterruptable process.

Use 'driveropts=burnfree' and nothing can interrupt the burn. In fact, the burn can stop completely and then resume without any problems.

Burning a DVD is different, because there is no burnfree, so I recommend using:
Where "$1" is an iso image.

Just for reference for CDs I use:

2 members found this post helpful.

Thanks a lot, H_TeXMeX_H. Your refences to -use-the-force-luke specially useful! And now some questions:
(a) So speed=1 forces minimum speed, even if the medium is not a "no-name", does it?
(b) And about -use-the-force-luke=, I suppose I can't put cdrecord options on the right of the equal sign because growisofs does not use cdrecord. Is this so?

not with any machine built in the last 15 years. A problem will only occur if the burn process is cpu starved long enough for the buffers to run empty. However, the cpu scheduler will share the cpu resource between user processes to prevent that from happening. On extremely slow hardware the situation may be helped by

• giving the burn process higher scheduling priority or scheduling class
• increasing buffer size
• reducing burn speed
• using a better cpu scheduler

1 members found this post helpful.

That is very interesting. So the cpu scheduler is software! I suppose in old computers the cpu time slices were all equal in lenght. I once skimmed over the P6 family of Intel processors manuals and saw that that was a world. I can't imagine what it must be todday.

The first three items are controllable through cdrecord. And the slower the speed the better the recording. Wrong: for the first item I can use nice. (But then nice is a CPU scheduler!)

It most certainly is. It's part of the kernel (and at times at the centre of a heated debate).


It has always been more sophisticated. There used to be a regular timer interrupt that was used by the cpu scheduler to pre-empt processes that hadn't yielded the cpu voluntarily, but there is any number of reasons why the running process might have been re-scheduled in between.

nice only sets a process parameter. The cpu scheduler is in the kernel. Btw, you can use other tools for more dramatic effect, like changing scheduling class (sometimes referred to as scheduling policy), particularly in conjunction with a more effective cpu scheduler (like rt or bfs).

http://rpm.pbone.net/index.php3/stat...azwa/schedtool
http://ck-hack.blogspot.de/2012/07/b...ux-34-ck3.html

This is just for info, not required for burning CDs.

1 members found this post helpful.

Thanks for more intersting facts and for the links, reading which, I saw:

To execute mplayer in SCHED_RR with priority 20. The priority arg is neededfor both SCHED_RR and SCHED_FIFO.

I've always wondered why I can't make mplayer play an audio disc (CDDA) in a descent way. No matter what mplayer package, no matter what CD, the buffer seems at times to empty, even if I augment the cache size. But reading the quote above, I think something could be done in a more radical o basic way! However, playing with the scheduler is something I, right now, wouldn't dare to do. May be by a combined reading of the man page and careful study of the subject I could make mplayer "behave himself" sooner than I expect!

Also, mplayer is too big a program for my machine. But it plays movies prity well. Unbelievably it is CDDA what it has trouble with.

indeed. there must be something wrong with mplayer.

It uses the lowest speed the drive can do, it doesn't matter about the medium.

growisofs is the only one with -use-the-force-luke options and it is completely different from cdrecord. You can technically also burn DVDs with cdrecord, but I prefer growisofs. Both programs can use mkisofs, but I recommend making the ISO beforehand so there is less chance of something taking too long and leading to buffer underflow.

1 members found this post helpful.

good point. With my previous comment I had this scenario in mind. When creating the iso file on the fly we open up to additional points of failure. In this scenario an I/O-heavy process can indeed interfere with CD burning. However, processing http requests shouldn't be of this nature.

In theory http requests shouldn't matter for this, only heavy disk I/O on the same disk will make a difference. With burning CDs and burnfree on, nothing should affect the burning process.

I want to ask a related question, so I'll use this thread. With one of my optical disk burners, a Philips SPD2417T, not exactly a high-end product, I'm getting

WARNING: Drive returns wrong startsec (0) using -150
Writing pregap for track 1 at -150

every time I use cdrecord on it. Would this be a serious failure?

No, it's normal. I get that for all my drives. I think it is just cdrecord being excessively strict.