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

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

Hi,

Bill Davidsen wrote:
> not passing
> multiple GB of once-used data through the system buffers and blowing
> everything else out.

I see some effects which could make the O_DIRECT
approach less superior to normal reading than your
scenario would let expect:

- If the (ISO) image is freshly generated then the
  formatter program just blew out everything else
  anyway. And for the ISO formatter it makes few
  sense to read O_DIRECT as it has a random access
  pattern on eventually small files.

- The cache area in RAM is nowadays quite large
  and i understand that the least recently used
  cache chunks get thrown out. While a growisofs
  read chunk is ageing in the cache for several
  seconds, any busy process can refresh its own
  chunks' read time.
  So i expect that the cache of growisofs' input
  stream can only blow out chunks which are as
  fewly used as its own chunks.
  
This would explain why i never saw the need to do
O_DIRECT reading: my ISO images are fresh, if
they are big. Typically they get piped directly
into the burner process.

I have one use case, though, where i burn two identical
copies of the same DVD image for redundancy reasons.
One-by-one via a single burner drive from an
image file on disk onto 16x DVD+R.
Even then i experience no undue impact on other
processes.
I also never noticed a difference when i switched
from growisofs to my own programs for that.


Is there a realistic scenario where O_DIRECT is
reproduciblrye superior to normally buffered reading ?
I ponder whether i shall offer a O_DIRECT option
with the source objects of libburn.


Have a nice day :)

Thomas