Re: Growisofs input cache (get away from dd?)
Hi,
> > 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.
The cache usage depends on the size, indeed.
But won't reading lots of small files without
memory cache be slow and disk clogging ?
> 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.
Yes. I put load on the cache.
But that's what it exists for.
It shall smoothen random access disk
reading at the expense of memory.
> Meaning that O_DIRECT is not worse (modulo specific
> and rare situations like one in originating report),
> so why the fear?-)
Because it is non-standard and a new idea.
I am sneaking around it and sniff whether
it might be edible.
On the write side i rather use fsync() to
avoid clogged buffers. Once per MB.
On the read side it did not come to me to
circumvent the cache.
> As implied low memory condition on interactively used system.
One can never have enough RAM :))
I will implement an O_DIRECT option on the read
side and look whether i can see advantages on
my system.
On the write side with disk file objects, i will
probably compare O_DIRECT with my periodic fsync().
(No fsync() and no O_DIRECT is bad if the disk is
slow. The write buffer size becomes very obtrusive.)
> there might be and are platform-specific
> limitations on O_DIRECT usage,
That's why i still poke the idea whether
it could bite.
Have a nice day :)
Thomas
Reply to: