Re: Growisofs input cache (get away from dd?)
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.
Reply to: