Re: Growisofs input cache (get away from dd?)
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:
O_DIRECT is not about superior performance, it's more about *maintaining
adequate _overall_ performance* in wider range of practical situations,
most notably under low memory conditions.
- If the (ISO) image is freshly generated then the
formatter program just blew out everything else
anyway.
Not if it used O_DIRECT too:-)
And for the ISO formatter it makes few
sense to read O_DIRECT as it has a random access
pattern on eventually small files.
It's not about size of individual files, but *sum* of their sizes. Also,
if you generate image file (as opposite to immediately burning it out),
you double the pressure on block cache as kernel would like to cache
both files you've read and recently generated portion of the image.
- 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.
Right. And if you wanted to record same image again you'd have to start
pulling data from disk *anyway*. So why put any pressure on block cache?
Why even create the situation when not-busy-enough processes would
have to fight for their memory when it can be avoided altogether? Note
that [not-so-]busy process would have as many meanings are there are users.
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.
Meaning that O_DIRECT is not worse (modulo specific and rare situations
like one in originating report), so why the fear?-)
Is there a realistic scenario where O_DIRECT is
reproduciblrye superior to normally buffered reading ?
As implied low memory condition on interactively used system. It's
commonly hard for developers to reproduce [and sometimes even understand
the problem], as they tend to end up with systems sized above average. A.
Reply to: