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