First of all as for "dd." Reference to dd in growisofs output is purely historical artifact: 1st growisofs version was nothing but a front-end to mkisofs and dd, and as such was even dependent on specific kernel DVD+RW support. But since version 2 growisofs is no longer dependent on dd nor explicit kernel support. So forget about dd:-)
>> In your situation i would test whether removing O_DIRECT >> solves your problem and eventually ask Andy for taking >> your results into respect. For reference. O_DIRECT makes perfect sense in vast majority of cases. Indeed, DVD images are commonly larger than amount of RAM in end-user system, which in turn means that sequential access to the image is bound to be non-cached, or has to be physically performed anyway. Simply because by the time you are reading end of image, block cache allocated for its beginning is lo-o-o-o-ong evicted. As growisofs [>=6.0] has internal ring buffer [acting as read-ahead in image burn case], the memory that would be allocated, evicted, reused for block cache for iso image is really better spent elsewhere. Of course if you access *same* iso image by several instances of growisofs at approximately *same* time, then it makes perfect sense to cache the data and minimize physical I/O. In other words O_DIRECT would indeed make more harm than use. But this is very specific and *rare* situation, so it shouldn't come as surprise that specific tuning might be due... > I have made a patch which removes the O_DIRECT code completely (it is only > used when opening image files anyway). I will try it out tomorrow and provide > the patch if the test was successful. There is a way to open image without O_DIRECT and without modifying source code: growisofs -Z /dev/cdrom=/dev/fd/0 < image.iso. Ta-dah... There are other things to think about. Most notably. Default ring buffer size in growisofs is 32MB. For optimal performance one has to make sure that sum of these buffers, plus buffer cache large enough to accommodate possible start time differences times recording velocity, plus memory of other programs essential for well-being of the system during recording, all these fits into RAM. You might find yourself in need to reduce growisofs buffer size to make it fit. Or you might have to consider adding more RAM to sustain that many simultaneous high-speed recordings... A. P.S. Always provide versioning information. There were specific bugs that affect performance in similar situations. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
