Re: Growisofs input cache (get away from dd?)
Well at least from an architectural point of view I have great doubts if it is
a good idea to use O_DIRECT for every application but DBMS.
In most cases it is a good idea to rely on the fact that the one who has
implemented caching in the operating system knew what he is doing. I also
think that there was scientific research on this topic so people have really
thought well about the best solution to implement such things.
The benchmarks which were discussed here seem to me synthetic, too. If you
benefit from O_DIRECT or not has really to do with the circumstances of
burning while burning your image.
The only case where O_DIRECT is better is, when you burn an image once which
is located on a mounted file system (for a long time). You need not to
benefit if,
* You copy it from a network share (smb://, http://) before burning
* You burn it twice
* You checked the ISO before by playing it with VLC
* You just newly created it
Because it really has much to do with the circumstances, you should more rely
on the operating system, and I do not think that such cases like described
above are rare.
However, as I did not do a scientific research if, at the end, you will
benefit from O_DIRECT in more cases than it leads to more disk I/O, I pledge
for considering the point from page 13 from
http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.html:
"Be careful in using O_DIRECT
If the application may want to use O_DIRECT but it is not self caching and you
can imagine a setup with enough RAM to cache all the working set of your
application then you should at least add a switch to turn off the O_DIRECT
behaviour, so if someone has that much memory he will be able to take
advantage of it (remember linux runs on the GS 256GByte boxes too ;).
Adding a switch to turn off O_DIRECT can often be a good idea so we can more
easily measure how much the buffered IO helps or hurts for a certain
workload."
So I will create a patch which adds such a switch to growisofs and post it to
the list, so it can be discussed for implementing. Otherwise I would need to
distribute a patched version of growisofs with turbojet...
Reply to: