[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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
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: