Re: Growisofs input cache (get away from dd?)

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

David Weisgerber wrote:
> So I will create a patch which adds such a switch to growisofs
Andy Polyakov wrote earlier:
> 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...

In my role as a frontend programmer for
growisofs i would first try whether "Ta-dah"
is a viable workaround.

> Otherwise I would need to
> distribute a patched version of growisofs with turbojet...

If you rely on a growisofs novelty then
you have to urge the users to install
newest dvd+rw-tools.
"Ta-dah" - if possible - would allow a
much better decoupling of your software
and the system installed tools.


Back to my role as backend programmer:

David Weisgerber wrote:
> 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.

Yes and no.
I assume that the kernel people are smarter than me
in respect to overall system issues.
But i assume that i am more informed than them when
it comes to the particular use cases of my programs.

me:
> "David and Andy, i believe that there are reasons"

Er, that should have been "Bill and Andy".
Some cranial short circuit with "David" and
"Davidsen". I apologize.


In general i lean(ed) more towards the opinion
of David Weisgerber.

But one argument of Bill and Andy is very strong:

  Why involve the caching in cases where one knows
  that it will be of no benefit ?

The main reason why i not flatly introduce in
libburn an option to use O_DIRECT is the system
dependency.
Andy disabled it in growisofs for Linux 2.4 kernels.
(Another reason why i never noticed any effect o
 my older computers.)


Have a nice day :)

Thomas