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... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
